perm filename CLWIND.MSG[COM,LSP]10 blob
sn#832109 filedate 1987-01-07 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Introduction
C00005 ENDMK
C⊗;
Introduction
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:
CL-Windows@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLWIND.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Windows-request@su-ai.arpa
Here is a list of the people who are currently on the mailing list:
Person Affiliation Net Address
Kent Pitman MIT kmp@mc
Dick Gabriel Stanford/Lucid rpg@sail
Carl Hewitt MIT hewitt-windows@mc
Don Allen BBN allen@bbnf
Dan Oldman Data General not established
Larry Stabile Apollo not established
Tom Kaczuarek ISI kaczuarek@isi
Dave Matthews HP matthews.hplabs@csnet-relay (I hope)
Dan Stenger TI stenger.ti-csl@csnet-relay
Gary Brown DEC gbrown@dec-marlboro
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Thomas Gruber Univ. of Mass. gruber.UMass-CS@csnet-relay
The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.
Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete.
∂23-Sep-84 1610 RPG Introduction
To: cl-windows@SU-AI.ARPA
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:
CL-Windows@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLWIND.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Windows-request@su-ai.arpa
Here is a list of the people who are currently on the mailing list:
Person Affiliation Net Address
Kent Pitman MIT kmp@mc
Dick Gabriel Stanford/Lucid rpg@sail
Carl Hewitt MIT hewitt-windows@mc
Don Allen BBN allen@bbnf
Dan Oldman Data General not established
Larry Stabile Apollo not established
Tom Kaczuarek ISI kaczuarek@isi
Dave Matthews HP matthews.hplabs@csnet-relay (I hope)
Dan Stenger TI stenger.ti-csl@csnet-relay
Gary Brown DEC gbrown@dec-marlboro
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Thomas Gruber Univ. of Mass. gruber.UMass-CS@csnet-relay
The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.
Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete.
∂02-Oct-84 1311 RPG Chairman
To: cl-windows@SU-AI.ARPA
Now that we've basically got most everyone who is interested on the mailing
list, let's pick a chairman. I suggest that people volunteer for chairman.
The duties are to keep the discussion going, to gather proposals and review
them, and to otherwise administer the needs of the mailing list. I will
retain the duties of maintaining the list itself and the archives, but
otherwise the chairman will be running the show.
Any takers?
-rpg-
∂13-Oct-84 1440 RPG Chairman
To: cl-windows@SU-AI.ARPA
No one has been nominated as chairman of the Windows subgroup. I
suggest Howard Cannon of Symbolics. If he is willing, and no one else
volunteers, he will become chairman. Please respond by October 24. At the
end of this month I want to see some ideas and proposals coming in on this
mailing list.
-rpg-
∂25-Oct-84 0944 FILE-SERVER%WHITE.SWW.Symbolics@SCRC-RIVERSIDE.ARPA Chairman
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 25 Oct 84 09:43:40 PDT
Received: from SWW-WHITE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 94510; Tue 23-Oct-84 23:01:25-EDT
Date: Tue, 23 Oct 84 20:06 PDT
From: hic%SWW-WHITE@SCRC-RIVERSIDE.ARPA
Sender: FILE-SERVER%SWW-WHITE@SCRC-RIVERSIDE.ARPA
Subject: Chairman
To: RPG@SU-AI.ARPA, cl-windows@SU-AI.ARPA
In-reply-to: The message of 13 Oct 84 14:40-PDT from Dick Gabriel <RPG at SU-AI>
Received: from SCRC-STONY-BROOK by SWW-WHITE via CHAOS with CHAOS-MAIL id 47648; Sat 13-Oct-84 15:37:52-PDT
Received: from MIT-MC by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 107864; Sat 13-Oct-84 18:32:38-EDT
Date: 13 Oct 84 1440 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Chairman
To: cl-windows@SU-AI.ARPA
No one has been nominated as chairman of the Windows subgroup. I
suggest Howard Cannon of Symbolics. If he is willing, and no one else
volunteers, he will become chairman. Please respond by October 24. At the
end of this month I want to see some ideas and proposals coming in on this
mailing list.
-rpg-
Ah, I see I received this message. I was worried that this mail wasn't
getting through, or was stuck at MC, or...
In any case, I respectfully decline the offer, not because I don't want
to do it but because of extensive traveling I don't feel I could be
reliable enough. I do hope to participate actively, though.
I suggest that DDYER would do a fine job as chairman.
--Howard
∂27-Oct-84 2148 RPG Hello folks
To: cl-windows@SU-AI.ARPA
We now have a chairman of the windows subgroup: Dave Dyer of Symbolics. I
think he will make an excellent chairman. For your information I am
including the current members of the mailing list.
I will now let Dave Dyer take over responsibility for the discussion.
David Matthews HP "hpfclp!windows%hplabs"@csnet-relay,
Jerry Boetje DEC Boetje@dec-hudson
John Foderaro Berkeley jkf@ucbmike.arpa
Steve Muchnick SUN "ucbvax!sun!muchnick"@berkeley
Howard Cannon Symbolics "hic%scrc"@mc
Dave Dyer Symbolics ddyer@isib
Skef Wholey CMU Wholey@cmuc
Richard Zippel MIT rz@mc
Ron MacLachlan CMU RAM@cmu-cs-c
John Peterson Univ of Utah jw-peterson@utah-20
Kent Pitman MIT kmp@mc
Dick Gabriel Stanford/Lucid rpg@sail
Carl Hewitt MIT hewitt-windows@mc
Don Allen BBN allen@bbnf
Dan Oldman Data General not established
Larry Stabile Apollo not established
Tom Kaczmarek ISI kaczmarek@isi
Dan Stenger TI stenger.ti-csl@csnet-relay
Gary Brown DEC brown@dec-hudson
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Thomas Gruber Univ. of Mass. gruber.UMass-CS@csnet-relay
Ron Fischer Rutgers fischer@rutgers
Dario Giuse CMU dzg@cmu-cs-spice
Neal Feinberg Symbolics feinberg@scrc-stony-brook
∂28-Oct-84 1054 DDYER@USC-ISIB.ARPA Initial questions
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 28 Oct 84 10:53:57 PST
Date: 28 Oct 1984 10:52:38 PST
Subject: Initial questions
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
Ok, since I have no idea what I'm supposed to do, I'll
just do what comes naturally. What is the scope of
this discussion? These questions come to mind:
What kinds of window hardware are we talking about? Plain
glass ttys? Bitmapped? Vector? Color?
What implementation technology? Particularly, will we use
whatever the CL standard for objects becomes, or structures.
Fonts? Text formatting? What is the boundary between
this mailing list and what "graphics" will discuss.
What about pointing devices?
-------
∂29-Oct-84 0917 DDYER@USC-ISIB.ARPA Initial Answer
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 29 Oct 84 09:17:19 PST
Date: 29 Oct 1984 09:12:53 PST
Subject: Initial Answer
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
[ Editors Note: Since this reply came to me rather than the mailing list,
I am reminded of the perpetual question; "To Digest or not to Digest"
For now, I will package any replies that come directly to me, and send
them to the mailing list from time to time. Messages sent to
cl-windows@su-ai will continue to be redistributed immediately.
DDyer@isib]
Return-Path: <KACZMAREK@USC-ISIF.ARPA>
Date: 29 Oct 1984 07:47:00 PST
Subject: Re: Initial questions
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>
Regarding interaction with the graphics group, I think we ought to try to
build on top of what they supply. I suspect that there is enough cross-
membership to insure that we have sufficient influence. (I haven't compared
the mailing lists so I could be wrong about that.)
[ddyer: I tend to look at it the other way; Graphics is an additional
behavior of windows, and graphics capabilities will be built out of
whatever we supply.]
As far as display hardware goes there seems to be two interesting classes--
"graphics" and glass ttys. Color is an orthogonal issue, isn't it?
Number of bit planes for black and white graphics falls in this same
category. Both graphic devices and ttys come in black and white (with
intensity levels) or color. Graceful degradation seems to be the
appropriate way to handle these issues. I believe the graphics people
having been looking at this issue for some time and have solutions for this
problem.
I would guess that if the graphics group does its job well, vector versus
bitmapped graphics should not be an issue. The resolution of the graphics
may be an issue however. Low resolution graphics devices seem a lot like
glass ttys as far as windows go. Storage vector graphics hardware (ala
old Tektronix stuff) does not lend itself to the kind of interaction one
expects from a window system so I think we can eliminate it. I believe the
graphics group also should make pointing devices less of a problem since
graphics standards have abstracted actions like "picking." I believe that
complex mouse buttoning will still be something of a problem.
Structures versus objects seems to be a difficult decision. Perhaps having
to wait for a object standard will be the best argument for structures.
Conceptually, objects are nice for the kind of interactions that occur in
the window world. Is efficiency an issue here? Object-oriented
implementations seems to rely on interpretation rather than compilation.
Is that because nobody has done it differently or is it too hard? Or
impossible? Or am I wrong about that?
[ddyer: flavors are compiled]
Tom
-------
-------
∂29-Oct-84 1045 boetje@DEC-HUDSON some initial answers(?)
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Oct 84 10:43:09 PST
Date: Mon, 29 Oct 84 13:39:39 EST
From: boetje@DEC-HUDSON
Subject: some initial answers(?)
To: cl-windows@su-ai.arpa
Ok, it's Monday morning and I'm ready to take on windows. This note is in
direct reply to Dave Dyer's set of questions over the weekend.
Let's take the terminology question first. I have a strong feeling that we
need to get this handled before much else can happen. One of the major
difficulties in this area is that there seem to be two different views of what
the term "window" refers to. Most everyone working on bitmapped screens these
days calls the funny rectangular areas (with borders and labels, in which you
can put text or draw lines) windows. The graphics community uses "window" in a
very different way. A window is really a way to specify a set of coordinate
transformations and a set of bounding coordinates for clipping purposes. You
can't ever see a graphics window. It takes a viewport to make that happen.
Viewports are potentially viewable objects. But of course in that graphics
world, there isn't a firm concept of borders and labels.
I will put forth the following radical suggestion: the graphics folks were
here first, so their terminology should take precedence. Windows and viewports
are strictly defined in the world of real graphics. A window is a set of
limiting coordinates (x-y min and max values) in some arbitrary system
(usually the coordinate system of the data values to be plotted). This defines
the aspect ratio of the eventual display of data. A viewport is another set of
limiting coordinates which are used to map the data plotted in coordinates of
the window to a displayable rectangle (this provides for clipping,
magnification, and transformation to the physical device).So we won't do
windows (sorry about the marketing slogan). We need to call those funny
rectangles on the screen something else.
Before I unveil my terms, let me introduce a concept into this arena. In both
the graphics world and whatever-we-call-the-current-thing world, there is the
idea of a displayable object. In the graphics world, viewports can be
displayable objects (when they map things from NDC space for example). They
can also be previously created "pictures" which can be used to make composite
images (for example, the symbol for a NAND gate in a CAD system). The common
term for this object is "segment". Segments can be replicated and scaled ad
nauseum to make a larger displayable object. The graphics world thus has a
model of composition by using displayable objects as well as basic line
drawing primitives.
In the bitmapped world, "windows" are considered displayable objects. In the
case of Symbolics, they also provide the idea of decomposition of their window
into "panes" (which can be treated as individual windows for many purposes).
Another way of looking at their system is that they treat their "window" as a
displayable object which can be composed of other windows. Their composition
process also involves a particular contraint system on the interaction between
the parts of a composed displayable object (resize one and the others adjust).
With all that said, I now introduce my own terms (liberally borrowed from
unnamed sources):
1. Virtual Display. This is what most folks think of as a "window" or perhaps
a bitmap (depending on whether it's visible or not). You may see it (touch it
and taste it if it's late enough at night) on the screen. It's a rectangular
area which may be made to appear on a physical display (hence the term virtual
display) which can have a border, a label, etc. Primitive operations can put
information into the display (like writing characters or drawing lines). If
they are not currently visible on the physical display, their current state is
kept and modified by primitive operations.
They can also be composed of other virtual displays with appropriate
constraints at the whim of the implemectation. It may or may not be on the
physical display and it may or may not be hidden obscured by other visible
displays). It can function as an I/O device for CL streams. And if you're into
the graphics side of the world, viewports map directly into the non-border
portion of virtual displays.
2. Windows and viewports retain (and will only be used for describing) their
traditional meanings in the world of graphics (which among other things means
that windows and viewports operate in coordinate systems other than that of
the physical display device).
3. Displayable object. Well, I gave the sense of it above. If we want to
strictly define it for CL, then we'll need to do some work on it. I'm inclined
to leave it alone for now and just use it by way of introducing concepts of
composition. We'd need to be very closely tied to the graphics folks if we
want to define it in the language.
Ok, enough on terms. Hardware... hmm... Curiously, the most limiting hardware
is the vector drawing equipment, because it's hard to change once you've put
it on the screen. My thought is that we should at least define operations that
can be done on a cell-oriented screen. We can define optional capabilities for
displays, but that gets us into the serious business of specifying how the
user program determines the capabilities that can be used on the runtime
device and what the error mechanism is for operations that can't be supported
on the current device. The GKS graphics folks have done this and the inquiry
functions outnumber the primitive operations.
On the software implementation, we should go for the least disruptive and
commonly implemented features (GCLISP has some nice display stuff on a small
machine). I think this means structures, not objects. We might want to define
an optional object interface to the displays, but I think we need the simple
level as well. Also, I don't want to wait around for the religious wars over
objects. We'll have enough of our own...
Fonts, et al. Ok, we need some optional ways to specify font information and
it's not clear that font bits are the best way to go. VAX LISP would probably
have a difficult time handling font information in strings (efficient strings
for us are one byte per character). Font information should be an ignoreable
parameter (VT200's don't do well when commanded to go into Times Roman).
Having a function that computes the actual screen size of a string in a
specified font is a must.
Text formatting. We need text primitives to write, erase and insert
characters. But I'm not anxious to get into the business of putting Scribe
into CL. But there should be enough functionality for the cottage industries
to write a formatting system on top of the CL primitives.
Boundary between this group and graphics. Ok, I've got a foot in both, so I'll
jump in. We should stick to the ideas of virtual displays and composition of
virtual displays. They should always operate in the coordinate system of the
device. The graphics world should get windows, viewports and segments and
operate in non-device coordinates. Our major interface then becomes a mapping
of viewport to virtual display with the graphics side worrying about the
scaling and clipping into the device (virtual display) coordinates.
Last topic for now... pointing devices. hmmm. They're needed for two purposes,
at least. One is to do operations on entire virtual displays (like popping
them to the surface). They other is to indicate a point or segment within a
virtual display. These operations can be handled with mouses and tablets and
can be simulated with cursor keys. We have to be careful not to get into the
business of defining a user interface to CL (pointing at a label brings a
display to the surface). But it would be nice to have some simple functions to
let users roll their own.
Indicating a point or segment is a bit more interesting and gets us involved
with the graphics group. Points within a virtual display need to be returned
in some coordinate system. Most bitmap systems give back a point in raster
coordinates. That's probably limiting. The graphics world likes them returned
in the original coordinates used to draw the picture. And picking graphics
segments has a close counterpart in defining/selecting a sensitive region.
Topic for next time.
Oh yes, color. Pick and stick to one of the international standards. There's
RGB (red, green, blue) and HLS (hue, lightness and saturation). Any of you
VideoText folks probably have yet another way. I have no real preference (just
a minor leaning to HLS) but I haven't figured out if I should grind an ax on
this or not. Issue deferred...
Jerry
∂30-Oct-84 0711 dzg@cmu-cs-spice.arpa Terminology, etc.
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 30 Oct 84 07:10:20 PST
Date: Tuesday 30 October 1984 09:33:00am-EST
From: dzg@CMU-CS-SPICE.ARPA
To: cl-windows@su-ai.arpa
Subject: Terminology, etc.
Message-ID: <0.0.dzg>
I mostly agree with Jerry Boetje. Let's use "window" for a set of bounding
coordinates; the confusion in the bitmap world is hopeless anyway. As an
example, on the Perq a 'viewport' is a rectangular portion of a display, and
a 'window' is essentially a viewport embellished with borders and a
'title'; on the Symbolics, a 'window' is essentially a viewport that may or
may not have borders and a 'label' (title).
I have a little problem with the term "segment", just because it is so
overloaded. I would try and suggest "symbol", a' la Newman & Sproull, just
because it's nice to talk about a symbol and a symbol instance. I realize,
though, that the word "symbol" is also overloaded...
One related question is transformations: can you only specify a
transformation (rotation, scale, offset) for symbols|segments, or can you
transform any graphical object in place? Do you want to be able to say
"This is an arc of a circle, center and radius such and such, and by the
way it is scaled up 3.2 and rotated pi radians"? Or do you always have to
wrap the arc in a symbol|segment to achieve the same effect?
I also agree that we should use the universally available Structures for
the software implementation, given that no universally accepted (or
implemented!) notion of object seems to be around the corner. The BIG
problem, here, is that if you are not very careful your structures turn out
to be a "display list" that the system maintains, and so you have to
duplicate them all to put the interesting stuff you want to deal with. One
of the ideas I am trying to work on is to SHARE your data structures with
the system, so that you can have all the nice slots you want in there that
are not graphical at all, while the system can store all its internal cute
optimization things in it. This is unfortunately difficult to do with
structures a' la DefStruct, since the slots are defined once and for all.
An object system would be much nicer, since the system can define all its
nasty things and you never need to know about them.
Fonts: the "best approximation" paradigm should apply. My approach would be
to have a very generic font definition (family name, face, size, rotation)
which would be mapped into whatever the system provides. Font names are
totally hopeless (What's a CPT10? Is it 10 points or 10 pixels? Or is it
the 10th font in the file CPT? And what's a CPT anyway?), so I think one
would end up having a device-dependent mapping between an "abstract font"
and whatever the system provides. The mapping would be very dull on the
VT200, for instance, but one should use an abstract specification
nonetheless.
I very strongly oppose any notion of text formatting. Only the very minimal
level of support, including obviously the ability to get device-dependent
font information (IN WORLD COORDINATES, not in device coordinates!), should
be present. More complex text formatting is A) highly dependent on personal
taste, and B) extremely difficult to do right for sophisticated
applications. I certainly don't want a window system at this level to have
to deal with kerning and italic corrections.
- Dario -
∂31-Oct-84 0723 STENGER%ti-csl.csnet@csnet-relay.arpa re: inital answers
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 07:23:51 PST
Received: from ti-csl by csnet-relay.csnet id ad00735; 31 Oct 84 10:18 EST
Date: 31 Oct 1984 0625-CST
From: Dan Stenger <STENGER%ti-csl.csnet@csnet-relay.arpa>
Subject: re: inital answers
To: cl-windows%su-ai.arpa@csnet-relay.arpa
Received: from csl60 by ti-csl; Wed, 31 Oct 84 09:13 CST
On terminology:
I agree with Jerry Boetje's proposal on the terminology that we should use.
We should settle on something so that we all understand each other. The
main problem I see with this is that the terms "windows" and "panes" are
well established in the Lisp community and we may just cause confusion.
On bounds of this group:
I am also in the graphics group. My view is that we should limit the
efforts of the windows group to virtual displays and other things that
need to work in device coordinates. The graphics group should handle
what is shown in the virtual displays.
On the software implementation:
I agree that structures are the way to go. Some implementations may not
want the object oriented programming system but may want windows. Also
the wait may just put us too far behind.
On display hardware:
It would be nice if what we come up with is compatible with vector refresh
and storage tube hardware but I do not think that we should concern ourselves
with it. The types of hardware which we do need to address are black/white
and color bitmaped terminals, and text only terminals.
In general I think we should try to design something that is concise, simple,
but very general. It should be implementable on small machines but be easily
extended (not restrictive) for larger machines.
Dan Stenger
-------
∂02-Nov-84 2330 DDYER@USC-ISIB.ARPA Real devices (mainly)
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 2 Nov 84 23:30:41 PST
Date: 2 Nov 1984 23:26:10 PST
Subject: Real devices (mainly)
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
There seems to be consensus that vector displays are outside
our domain. If there are no devotees of vector displays out
out there, I'll consider it official.
I liked "virtual display", but one term isn't a complete glossary.
Several messages have cast a word in favor of supporting ordinary
terminals; but I wonder just how much one can do, especially if
"virtual display" is taken to imply "multiple virtual displays".
In practice, won't terminals be restricted to one or two virtual
displays, all the same width as the screen? I've done quite
a bit of display hacking on ordinary terminals, and found anything
fancier to be aesthtically awful, even if technically possible.
There simply isn't enough real estate to distinguish more than
a few windows, aren't display capabilities to provide margins
and borders, and the devices themselves don't operate fast or
reliably enough to allow manipulation of arbitrary blocks of
characters in a way that is acceptable to users. Shouldn't we
take this ugly bit of reality into account?
I'm not necessarily proposing we punt terminals entirely, but
we should at least consider defining a limited set of primitives
for terminals sufficient for input editing and (maybe) emacs style
editing.
I also have doubts about several mentions of "device coordinates"
as the appropriate substrate for virtual displays. One at least
needs to be able to speak of either "characters" or "pixels", to
accommodate ordinary terminals and bitmaps, but once pixels are
introduced, a whole nest of other problems surface; such as
aspect ratio, variable width and height of fonts, and the variable
size of pixels on different displays.
For a particular display, one could of course tweak things into
the right device coordinates to give the desired effect, but we
are speaking "portable" here, so need to at least address the question
of transmitting the author's intent to foreign systems.
Just to finish on a concrete point, consider Symbolic's color
displays, where the "same size" characters (in device coordinates)
border on unreadable compared to the same text on the B&W screen.
Also, consider that a single pixel height horizontal line on a
noninterlaced screen is fine, but on an interlaced screen it is
probably unacceptable due to excess flicker.
No program that operates in "device" coordinates can ignore facts
of life such as these. We need to strike a balance between providing
access to the raw facts, and hoping programs cope with all the possible
implications, and attempting to abstract intent into our specs and letting
the implementation cope with the ramifications.
-------
∂03-Nov-84 0747 FAHLMAN@CMU-CS-C.ARPA Goals
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Nov 84 07:47:49 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 3 Nov 84 10:47:55-EST
Date: Sat, 3 Nov 1984 10:47 EST
Message-ID: <FAHLMAN.12060631562.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: cl-windows@SU-AI.ARPA
Subject: Goals
In my opinion, the window group is really in the business of developing
one or more optional semi-standards. What I mean by that is that I
don't think that the Common Lisp specification should require any
particular sort of display or window system in order for something to be
called Common Lisp. Display technology is moving pretty fast, and we
wouldn't want to rule out a Common Lisp in a wristwatch or a Common Lisp
running on a brute-force machine with no display of its own.
Furthermore, each machine running Common Lisp will have a few
specialized high-performance tricks available that users will want to
access for the most demanding applications: one machine might have a
hardware font and vector generator, another might have an incredibly
smart rasterop, and so on.
But what we can and should do is to develop one or more clean interfaces
for doing some collection of popular things on certain popular families
of display technologies. Implementors will be encouraged to provide
these standard interfaces on their machines wherever they make sense,
and people developing display-oriented code will then have the option of
writing it using the portable interface, for easy portability across a
class of machines, or of writing it to make the best possible use of a
given machine using whatever tense non-standard mechanisms may be
available.
It seems to me that three families of display device are going to be
important in the near future: 24x80 character terminals with varying
degrees of crude graphics support, high-resolution (at least 600 x
800) monochrome bit-mapped displays with some sort of pointing device,
and high-res bit-mapped displays with color. Rather than ruin the
interface we develop for bit-mapped displays by trying too hard to make
it all work on ASCII terminals, I propose that we define three separate
interfaces:
Level 1: Can be implemented on the majority of ASCII termianls.
Level 2: Assumes bit-mapped graphics, reasonable resolution, and a
pointer.
Level 3: Same as above, but with color.
Software developers can target their software to raw common Lisp or to
any of these levels, depending on the capability they need and the
market they wish to address, or they can go native on a single
machine/system. Maybe levels 2 and 3 can be collapsed into one.
This is set up as a sort of hierarchy, since I am assuming that any
machine providing level 2 support will also provide level 1 support and
so on. But the situation is really not hierarchical -- one might
imagine vector displays as wanting a different kind of interface
altogether.
The most important need right now is to come up with something for level
2, since the vast majority of Common Lisp implementations (not weighted
by number of users) is on machines of this class.
-- Scott
∂04-Nov-84 1816 JW-PETERSON@UTAH-20.ARPA Some responses...
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 4 Nov 84 18:16:37 PST
Date: Sun 4 Nov 84 19:16:54-MST
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Some responses...
To: cl-windows@SU-AI.ARPA
VT100's. The 24x80 terminal may not be dead, but is quickly dying. A
reasonably intelligent bitmapped terminal with a mouse runs around $2K, and
will shortly drop to the VT100 [& clones] price range - this seems like a
good "lowest common denominator" level.
Fonts. The discussion of fonts and formatting brings up an interesting
analogy: When the world migrated from TTY's to CRT's, many programs broke
(or just "looked ugly") because they couldn't deal with lower case input or
output. The same sort of thing appears to be happening again, only this
time things are breaking (or just not looking right) because they can't deal
with multiple fonts - particularly ones with proportional spacing. Having
at least some formatting facilities inherent in the window system (e.g., tab
stops that work correctly with proportional spaced fonts) would make the
programmer's life noticeably easier.
Units of measure. Is anything wrong with measuring things in Pixels? It
makes life much, much simpler (both conceptually and pragmatically) to
define screen coordinates in pixel units. There is nothing very "display
specific" about pixel units of measure, particularly when you consider
"Virtual Displays" are usually of various sizes on the same screen. As long
as we use digital computers, screens will be measured in discrete units -
both graphics and window packages might as well behave the same way.
(An interesting discussion of this is presented in "A Language for Bitmap
Manipulation" by Guibas & Stolfi in the July '82 Transactions on Graphics.)
-------
∂19-Nov-84 0019 DDYER@USC-ISIB.ARPA Proposals and questions
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 00:19:31 PST
Date: 19 Nov 1984 00:18:26 PST
Subject: Proposals and questions
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
I like Scott Fahlman's notion of defining two sets
of protocols, one for simple terminals and the other
for rasters. Presumably the terminal protocol would
use characters and lines as its units, while the
raster protocol would use either characters or pixels.
Are there any existing standards we might use as a
starting point? I'm hoping for something more abstract
than the lisp machine window system manual! The first
proposal circulated is likely to become the de facto standard.
In accordance with the above, I suggest the following
framework:
Each virtual display divides the world into three parts,
INSIDE, BORDERS, and OUTSIDE.
INSIDE a virtual display, two protocol sets are defined,
a "character oriented set" and a "raster oriented set".
The character oriented set deals with size, positioning,
font and other characteristics of characters. The
raster oriented protocol also addresses characters,
but also any other graphics and display primitives.
It is permitted for an implementation to implement only
the character oriented protocol.
OUTSIDE a virtual display, protocols deal with its
size, position, visibility and so on with respect to
its superior.
I'm not sure how to encapsulate the notion of BORDERS
succinctly. The best I can think of at the moment
is that borders are a specialization of the more general
notion of "clipping region"; that a window is defined
by a clipped region within its superior, and may
in turn define an inferior clipping region.
ANOTHER NEW QUESTION
I'm personally a little worried by the consensus to implement
virtual displays using structures. By way of bringing my
concerns to the surface, I'll pose a question:
How much user extensibility to window system behavior will be
expected/permitted, and how will the data structure and procedural
hooks for that extensibility be supported?
I think it is important that extensibility be a goal, and that
"extended" windows (oops! virtual displays!) be as well integrated
and as efficiently implemented as the system's supplied windows.
I know how to do this in an object oriented window system. Tell me
how you'll do it in a structure based system.
-------
∂19-Nov-84 2035 WHOLEY@CMU-CS-C.ARPA Proposals and questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 20:34:25 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 19 Nov 84 23:33:14-EST
Date: Mon, 19 Nov 1984 23:33 EST
Message-ID: <WHOLEY.12064965182.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Cl-Windows@SU-AI.ARPA
CC: Dave Dyer <DDYER@USC-ISIB.ARPA>
Subject: Proposals and questions
In-reply-to: Msg of 19 Nov 1984 03:18-EST from Dave Dyer <DDYER at USC-ISIB.ARPA>
Here are some of my thoughts on "virtual displays," both their specification
and their implementation (via structures).
There are (currently) about three coarse levels in virtual display fanciness
that a virtual display system should try to support:
Glass TTY with at least an addressable cursor (e.g. ADM-3A)
"Smart" CRT terminal (e.g. Concept-100, VT-200)
Bitmapped displays
I believe that any virtual display should support all operations (we have yet
to decide on the operations, but my point is that something like DELETE-CHAR
can be performed on any of the above, albeit with different performance). Non-
bitmapped terminals could be treated as having 24 by 80 (or whatever) pixels,
and a 1 by 1 font.
The redisplay module of a text editor will want to use different screen update
algorithms depending on the sort of virtual display it is writing to. Thus, a
virtual display should be able to provide information about the relative
efficiency of its operations. At the very least, a programmer should be able
to find out in which of the three categories listed above a virtual display
belongs. The editor's redisplay algorithm can then be tuned to the particular
output device. The casual programmer could of course opt to ignore this extra
information. The virtual display machinery could do all kinds of redisplay
optimization itself, but I believe that certain decisions are best made in the
client program.
Thus, the different "protocols" that Scott suggests would be kept at a level
below the virtual display operations, but programmers that wanted to could
easily figure out useful things about the implementation of a particular
virtual display.
We at CMU have had a good deal of success implementing streams with structures,
which leads me to believe that they'll be sufficient for implementing virtual
displays as well. Our stream structures store both functions ("methods") and
data ("instance variables"). Common Lisp DEFSTRUCT provides inheritance
through the :INCLUDE option, which makes streams (somewhat) easily extensible.
I realize that this system is less flexible than one built on flavors (or any
other real object-oriented programming system), but it is highly portable, and
gives you 90% of the extensibility you'd ever want.
Thus, we might define a virtual display like this:
(defstruct vd
"The root Virtual Display structure."
;; Methods:
display-char ; Method for Display-char
display-string ; Method for Display-string
delete-char ; Method for Delete-Char
...
;; Instance variables:
width ; Width in pixels
height ; Height in pixels
cursor-row ; Row that the cursor's on
cursor-column ; Column the cursor's on
...)
(defun display-char (vd char)
"Displays the Char at the current cursor position of the VD,
moving the cursor appropriately."
(funcall (vd-display-char vd) char))
...
Then we could define a particular kind of virtual display like this:
(defstruct (c100-vd
(:include vd
(display-char c100-vd-display-char)
(display-string c100-vd-display-string)
...))
"The VD for Concept-100 terminals."
;; Additional instance variables:
stream)
(defun c100-vd-display-char (vd char)
(write-char (c100-vd-stream vd) char)
(cond ((char= char #\newline)
(setf (vd-cursor-column vd) 0)
(incf (vd-cursor-row vd)))
(t
(incf (vd-cursor-column vd)))))
...
That's just an example of the sort of thing one can do, and none of the
particular operations should be taken as suggestions for how a virtual display
should work.
Yes, it's more verbose than flavors, but it is portable and perhaps more
efficient than a flavor-based system would be. Such a system CAN be extended
by the user. Do you still think we'd be too constrained by implementing a
virtual display system with structures?
--Skef
∂19-Nov-84 2220 FAHLMAN@CMU-CS-C.ARPA Proposals and questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 22:17:38 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 20 Nov 84 01:16:25-EST
Date: Tue, 20 Nov 1984 01:16 EST
Message-ID: <FAHLMAN.12064983964.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Cl-Windows@SU-AI.ARPA
Subject: Proposals and questions
In-reply-to: Msg of 19 Nov 1984 23:33-EST from Skef Wholey <Wholey>
I agree with much of what Skef Wholey says -- especially the part about
being able to find out which class of display device you have -- but I
don't think I agree that "any virtual display should support all
operations". The problem is that there are some things you want to do
on a bitmap that just have no counterpart on a 24x80 ASCII terminal
(smart or not). If we throw all of these things out, we get an interface
for bit-mapped displays that is less powerful than it should be, which
means that more users will write their code using non-standard calls to
get at the display's real power.
Probably the right move is to make the operations for the feeble
displays a subset of those available on the more powerful ones. In some
cases, we might want the operations for more powerful displays to
recognize additional keywords (such as :COLOR). We should try to keep
the number of distinct levels fairly small, however.
On the issue of whether to use objects, I think that we cannot define an
object-orineted interface until the Common Lisp community settles on
some particular object-oriented system as being required on all
implementations (though other object systems might co-exist with this).
I don't expect to see this any time soon -- if a standard is to emerge
at all, it will only be AFTER people have had a chance to play with
portable Flavors and Loops and assorted other things and decide what
they like. I think that we can define a reasonable set of
somewhat-extensible interfaces in a portable non-flavorish way; if we
have to sacrifice some extensibility, that's better than having no
common window interface at all.
-- Scott
∂20-Nov-84 0736 boetje@DEC-HUDSON documenting implementations
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 20 Nov 84 07:35:44 PST
Date: Tue, 20 Nov 84 10:36:01 EST
From: boetje@DEC-HUDSON
Subject: documenting implementations
To: cl-windows@su-ai.arpa
I think the discussion of structures vs object implementation is getting a
little off track. The issues (it seems to me) revolve around the form of the
creation, accessing and setting functions for virtual displays and the method
by which the user can extend the functionality of the virtual display system
Let me address some high level considerations of each issue.
When I say that I prefer a structure implementation for the CL standard, I'm
not saying that I intend that the DEFSTRUCT for various things be defined in
the standard. My intention is that we document and standardize creation,
accessing and setting functions that look like
(setq display-1 (make-virtual-display ...))
(virtual-display-label display-1)
(setf (virtual-display-label display-1) ...)
as opposed to instancing of objects and sending messages to the instances. I
think that under no circumstances should we document a particular DEFSTRUCT
implementation and require all Common LISPs to have this. I think that the
only reason to do this (and it's part of the example Skef gives) is to allow
users to support output devices not explicitly supported by the vendor. This
will get us rapidly down a rat hole of terminal support issues. Support of
"non-vendor" terminals should be an issue for the vendor to address in
whatever way is most efficient on his system. On the other hand, functions
such as SET-CURSOR-POSITION should exist in all the CL implementations and do
the right thing on all supported terminals. If the vendor provides an
implementation dependent way to define support for other terminals, then the
positioning function will do the right thing on these other terminals as well.
Extending the capabilities of operations on virtual displays is a real issue.
On the other hand, it's not clear that we have to address this right now. I
propose that we investigate defining a fairly "complete" range of
functionality which assumes the availability of a nice (color, bitmapped)
display and then look at subsetting this functionality to cell-oriented
terminals. A part of this may be defining a number of inquiry functions which
let the program tailor itself to the capabilities of the run-time device. This
means that we're likely to end up in the same place as the GKS standard which
has more inquiry functions than all the other kinds of function combined.
We can probably have some high level inquiry functions that let the user know
the general category of device (bitmapped, color, vector, cell, etc). Each
category would have a certain level of functionality that's required (by the
standard) for that device and a certain set that's optional and up to the
implementation (eg, narrow virtual displays on a VT100).
∂20-Nov-84 0850 WHOLEY@CMU-CS-C.ARPA Virtual Displays
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Nov 84 08:49:57 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 20 Nov 84 11:48:43-EST
Date: Tue, 20 Nov 1984 11:48 EST
Message-ID: <WHOLEY.12065099060.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: CL-Windows@SU-AI.ARPA
Subject: Virtual Displays
From: Scott E. Fahlman <Fahlman>
I don't think I agree that "any virtual display should support all
operations". The problem is that there are some things you want to do
on a bitmap that just have no counterpart on a 24x80 ASCII terminal
(smart or not). If we throw all of these things out, we get an interface
for bit-mapped displays that is less powerful than it should be, which
means that more users will write their code using non-standard calls to
get at the display's real power.
I believe that the sorts of things you're talking about are in the domain of
CL-Graphics. I could be wrong. Could you give me an example of such
operations? I have a feeling that either they should be hidden by something
very high level (e.g. HALFTONE-RECTANGLE could really halftone a portion of a
raster display, but put a portion of a Concept-100's screen into half-bright
mode), or that they can be implemented by mashing vanilla CRT's into 24x80
raster displays using 1x1 fonts (MOVE-RECTANGLE could do a BITBLT on a raster
display, but actually copy stuff around on other terminals (actually, for dumb
termiansl this would require the VD system to maintain a screen image, which
may or may not be a good idea (but Concept-LNZ's DO have such an operation))).
Perhaps we need to decide on operations before we determine if there needs to
be the distinction that Scott suggests there ought to be. I think a virtual
display should try its best to perform an operation, but quietly ignore the
request if it can't hack it. It could bum someone out if a nifty piece of
software didn't run on her computer just because she had a dumb terminal. If
instead, the display just didn't look as nifty on an ADM-3A as it does on a
Lisp Machine, then the user will probably be forgiving.
From: boetje at DEC-HUDSON
I think the discussion of structures vs object implementation is getting a
little off track.
I was attempting to show that the niceness of an object-oriented approach could
still be had within the Common Lisp language, and with structures. Perhaps I
should have said "Object oriented programming is a style, and one can write
stylized Common Lisp," and left out all the code in my last message.
My intention is that we document and standardize creation, accessing and
setting functions that look like
...
as opposed to instancing of objects and sending messages to the instances.
Sure. Note that the Display-Char function (intended to be the user-level call)
in my example hid the object oriented implementation. Streams are the done the
same way, for us.
I think that under no circumstances should we document a particular
DEFSTRUCT implementation and require all Common LISPs to have this. I think
that the only reason to do this (and it's part of the example Skef gives)
is to allow users to support output devices not explicitly supported by the
vendor.
So we're just working on a spec here, and not a portable implementation. Ok.
I think a portable implementation or two will come out of this, though. The
people doing those implementations probably want to think hard about
extensibility for the sake of porting to new environments in addition to
supporting new devices.
We can probably have some high level inquiry functions that let the user
know the general category of device (bitmapped, color, vector, cell, etc).
Each category would have a certain level of functionality that's required
(by the standard) for that device and a certain set that's optional and up
to the implementation (eg, narrow virtual displays on a VT100).
I have a feeling that trying to do things in explicit levels is going to let
capabilities of some terminals fall through the cracks. I claim that the
problem Scott brought up in the first paragraph quoted above can work in
reverse -- some character-oriented CRT's can do operations like
raster-oritented displays, and others can do different ones. Maybe this isn't
a problem, but we can't tell for sure until we get into specifics. Anyone up
for that?
--Skef
∂21-Nov-84 0724 FAHLMAN@CMU-CS-C.ARPA Virtual Displays
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 07:23:14 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 21 Nov 84 10:22:01-EST
Date: Wed, 21 Nov 1984 10:21 EST
Message-ID: <FAHLMAN.12065345435.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
Cc: CL-Windows@SU-AI.ARPA
Subject: Virtual Displays
In-reply-to: Msg of 20 Nov 1984 11:48-EST from Skef Wholey <Wholey>
I'm not sure if my view of the dividing line between CL-WINDOWS and
CL-GRAPHICS matches other people's. I had been assuming that such
things as the primitive calls to display characters in a window at
arbitrary places, draw lines, color in rectangles, and so on were the
provine of the window package, and that any graphics standard is more
concerned with higher-level software to help decide which lines to draw
where. (If graphic means anything that is written into a virtual
display at all, then we have to consider graphics and windows together
because at that level they are inseparable.)
If my view of the division is correct, then there are several examples
of things that a raster-scan display could do that would have no
immediate counterpart on a dumb terminal: draw lines from one point to
another, display an arbitrary character from an arbitrary font at a
specific location specified in pixels, rotate a chunk of the screen,
return a mouse-click (or some other kind of pointer-selection) in window
coordinates, etc.
I think that it is a terrible mistake to rule out any of these
operations for raster displays just because there is no good equivalent
on an 24x80 character terminal. I also think that it is not in general
possible to have the built-in window-based software fake all of these
things in "the best way possible" on the dumb terminal. There's just no
good way to fake a drawing program on an Adm-3A, and I'd rather have the
software fail cleanly than waste a lot of time trying. Maybe a clever
application programmer can figure out some way to fake his particular
drawing program on a dumb terminal, using the impoverished set of
operations available there, but that should be his problem and not the
Lisp implementor's problem.
So, revised proposal:
We divide features that a diplay might have into broad classes that tend
to go together: Multiple windows, Advanced cursor commands, Pixel
operations, Pointing device, Color, Multiple Fonts, etc. Some of these
have parameters, such as the X and Y dimensions of the screen in
characters or pixels. Each display/implemenation is required to
indicate which of these things it has and the values of its parameters,
and therefore what operations it supports. Software will be written to
assume some set of these feature groups, and the necessary support will
be advertised with the documentation for the software. If I want my
package to run on ANYTHING, I assume a very minimal set of support; if I
don't want to live with those restrictions, then I assume more. The
best software providers will conditionalize their code so that if some
feature like color is present, it is used, but if it is not present they
compensate for this in some other way; others may choose not to bother
trying to cope with dumb displays.
-- Scott
∂21-Nov-84 0914 DDYER@USC-ISIB.ARPA Implementation strategy
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 09:14:26 PST
Date: 21 Nov 1984 09:13:20 PST
Subject: Implementation strategy
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
Now that I've lighted the fire, I'll add my contribution to the fuel.
We have to define virtual display operations in a way that is acceptable
to the major implementations, or else the definition will simply be
rejected as brain damaged and ignored. In particular, it should be
obvious that Symbolics isn't going to re-implement their window system
using structures. It's just as obvious, as was pointed out, none
of the other CL implementations will have a robust and portable object
oriented system for an indeterminate time. Therefore, we must define
something compatible with either strategy, and preferably, one that
will permit the underlying implementation to change, as object
systems become available.
What this amounts to is defining a limited object oriented system,
which maximizes information hiding but makes no commitment about
implementation. The last time I implemented such a system, my
basic primitives looked like this.
(SCREENOP <<window>> <<operation>> &rest args)
Honest Injun, I came up with it before I ever wrote my first DEFFLAVOR!
This was implemented by a hairy macro, which expanded to structure
manipulations appropriate to the operation. To hack efficiency,
one "operation" was :GET-HANDLER-FOR and another was :INVOKE-HANDLER-FOR.
We might also want an environment macro like
(WITH-SCREEN-ENVIRONMENT (VAR WINDOW) --)
Where WINDOW would be decoded (whatever that means) so that references
to VAR would know the exact type of the operand.
The advantages of this approach are that it is easy to transform
into efficient code for most any implementation, it avoids embedding
implementation details in user code, it makes screen manipulations
easily identifiable, and it avoids polluting the global environment
with arbitrarily many names of operations. I strongly favor this
kind of surface structure for invoking display operations.
The problem of creating an abstract syntax for defining window types
is stickier.
-------
∂21-Nov-84 1048 KACZMAREK@USC-ISIF.ARPA Re: Virtual Displays
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 10:48:12 PST
Date: 21 Nov 1984 10:45:02 PST
Subject: Re: Virtual Displays
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc: cl-windows@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12065345435.BABYL@CMU-CS-C.ARPA>
Typical graphic standards provide a great deal of functionality regarding
the display of lines, circles, points, raster images, and characters. They
also provide for clipping regions, rotation of images, panning, zooming, and
scaling. I think that a window package should be built on top of graphic
support. We should assume the existence of font support (including producing
bitmaps for text strings), clipping, line drawing, shading, texturing,
coloration, etc.. We should also presume high level primitives for
pointing devices ala GKS and the Siggraph Core standard.
I suggested this in an earlier message but no one seemed to pick up on it
other than to say they wanted to do all the low-level stuff. I would like
to get a measure on how many people think that windows are at a higher
level than graphics. I see windows as graphic structures with fairly
restrictive constraints--they are a major component of the user interface
with highly stylized behavior. They have to be flexible enough to allow an
application programmer to mold the user interface to his liking, yet
restrictive enough so that the user is not overwhelmed by inconsistencies.
I think we ought to check with the graphics group also to get their
feelings to make sure we are not duplicating efforts.
Tom
-------
∂21-Nov-84 1250 greek@DEC-HUDSON Terminal features and graphic functions
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 12:49:51 PST
Date: Wed, 21 Nov 84 15:50:10 EST
From: greek@DEC-HUDSON
Subject: Terminal features and graphic functions
To: cl-windows@su-ai
I basically agree with what Scott says about categories of features.
Perhaps we might even end up with some standard symbols in *FEATURES*
for testing by programs. However, I'm dubious as to the patience
of developers as they try to write code that uses as many features
as possible but avoids ones not on the current terminal. This kind
of code is difficult to write, and people just tend to write
for the lowest common denominator, or say "screw" to all but the
smartest terminals.
I think we can define virtual displays that will work pretty well
on many kinds of terminals. If we said that all, or almost all,
operations had to work on all terminals, and forced implementors
to think of ways to do these on dumb terminals (or noop them), we
would be doing the world a favor. As for complex graphics, that
have no counterpart on dumb terminals, perhaps we shouldn't be
treading on that ground. Graphics is not a solved problem.
Dave - I don't understand why your statements about window
compatibility with existing implementations leads you to believe
that the operations must be object-oriented. What's wrong with
50 functions? If Symbolics implements these as macros that turn
into flavorful things, no problem. Streams are object-oriented,
structures aren't, hash tables aren't, arrays aren't. Why start
now, when we haven't agreed on object-oriented features for CL?
(Read that as "streams aren't object...").
- Paul
∂21-Nov-84 1434 @MIT-MC:MONTALVO@MIT-OZ Re: Virtual Displays
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 14:34:23 PST
Date: Wed 21 Nov 84 17:31:34-EST
From: Fanya S. Montalvo <MONTALVO%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Virtual Displays
To: KACZMAREK@USC-ISIF.ARPA
cc: Fahlman@CMU-CS-C.ARPA, cl-windows@SU-AI.ARPA, MONTALVO%MIT-OZ@MIT-MC.ARPA
In-Reply-To: Message from "Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>" of Wed 21 Nov 84 10:45:02-EST
I think a lot of the issues being raised by cl-windows are relevant to
cl-graphics, and that the relationship between windows and graphics
should be discussed by cl-graphics, also.
I see windows as a subset of graphics. Support for windows is a
specific kind of functionality that a graphics package may or may not
have. As a subset, it's neither higher nor lower than graphics. It
may rely on low-level primitives, but in turn, some even higher level
functionality may rely on it.
And by the way, I'm on cl-graphics also, and may have missed the
discussion of how the division was being made. If it was already
discussed just forward the relevant messages (not too many please).
Fanya
-------
∂26-Nov-84 0717 boetje@DEC-HUDSON graphics, virtual displays, and terminals
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 26 Nov 84 07:16:27 PST
Date: Mon, 26 Nov 84 10:13:21 EST
From: boetje@DEC-HUDSON
Subject: graphics, virtual displays, and terminals
To: cl-windows@su-ai.arpa
On categories of features, here's one suggestion for a basic division...
Take some dumb terminals of the VT100 class. These have the ability to
position a cursor to an arbitrary cell location and write ASCII characters
This is sufficient capability support virtual displays which can have a border
and a label. The set of operations has to be restricted to manipulating text
on a cell-oriented terminal (ie, no proportional fonts). There is a suprising
amount that can be implemented on such a terminal: show arbitrary sized
displays, insert and delete characters (easier on a cell terminal), scroll
lines of text in a display, occlude displays, pick and point via cursor
manipulation and even draw horizontal and vertical lines. For a dumb terminal,
that ain't bad.
The other category then becomes the bitmapped tubes. Let's just assume they
can do whatever we think up (although character insertion and deletion is
harder on these terminals). It's up to us to establish a reasonable set of
operations that should be supported.
So I'd choose two categories: the kitchen sink and the text only. The text
only terminal is required to be cell-oriented and have the capability to
position the terminal cursor at an arbitrary cell position. It can support all
the capabilities needed for a screen editor. The kitchen sink terminal is
bitmapped and can support an arbitrary level of complexity in its display
operations.
On the division of virtual displays and graphics...
The more I've thought about it, they really are fairly separate topics which
have one area of overlap. Each topic has a number of basic operations and
concepts which don't relate at all to the other. For example, a discussion of
virtual displays gets into issues of display management which includes ideas
such as stacking, occlusion and selection. Graphics deals a lot with
coordinate transformation, line drawing, graphical objects and area fill.
The one area of overlap can be neatly defined if we define the picture area of
a virtual display to be that portion of a display inside of things like labels,
borders and margins. The picture area is where most everything of interest
happens in a virtual display. The picture area is also allowed to be a
graphics viewport onto some data space (such as NDC for you GKS fans). If we
accept this definition, then the tasks of the display committee and the
graphics committee become a bit easier. We need to refine things such as the
coordinate system of the virtual display. Once this is done, the graphics
committee can concern itself with coordinate transformations, composition,
basic operations and picking. The display committee can be concerned with
management of virtual displays, use of a virtual display in place of a CL
stream, and the definition of what surrounds a virtual display (labels,
borders, margins, etc).
Jerry
∂08-Dec-84 1642 DDYER@USC-ISIB.ARPA Easy Questions
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 8 Dec 84 16:42:42 PST
Date: 8 Dec 1984 16:41:41 PST
Subject: Easy Questions
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
I'd like to gauge the "real world" concerns of the members of this
list regarding portable windows. Feel free to editorialize. The
questions are:
What existing, under development, or planned programs
would use common lisp's window system if it had one?
What existing, under development, or planned programs
would NOT use common lisp's window system, even if
it had one? Why?
-------
∂08-Dec-84 1927 FAHLMAN@CMU-CS-C.ARPA Easy Questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Dec 84 19:27:18 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 8 Dec 84 22:27:55-EST
Date: Sat, 8 Dec 1984 22:27 EST
Message-ID: <FAHLMAN.12069934029.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dave Dyer <DDYER@USC-ISIB.ARPA>
Cc: cl-windows@SU-AI.ARPA
Subject: Easy Questions
In-reply-to: Msg of 8 Dec 1984 19:41-EST from Dave Dyer <DDYER at USC-ISIB.ARPA>
This question is not so easy. The answer depends totally on what the
standard Common Lisp window system ends up looking like. In the Spice
Lisp system (on the Perq, at present) we now have a simple set of Lisp
function calls that gives us efficient access to the window and graphics
operations available in the system: window creation and deletion, what
appears in the title line and progress bar, what appears in the icon
associated with the window, line drawing, character moves, raster ops,
reading from the screen bitmap, and so on. Actually, all of these
services are provided outside of the Lisp process, and the calls turn
into messages to the system kernel or to the screen-manager process, but
the user doesn't need to know that.
If the window/graphics standard turns out to be a set of function calls
that gives us access to all of the same kinds of operations, then we
would probably use it for most of our graphics-oriented applications and
possibly even for the Hemlock editor. This would become the standard
set of screen-oriented function calls in our Lisp system.
If the standard provides access only to a small subset of the Spice
display facilities, or enforces a substantially different view of the
display abstractions than our system supports, or if it is grossly
inefficient for some reason, then we would probably use the native Spice
calls for all of our local programming, but would occasionally translate
certain vanilla applications or utilities into the Common Lisp
graphics/window standard for export.
If, in the interest of extensibility or whatever, the standard window
system ends up being object-oriented and ultra-hairy like the current
Zetalisp window system, I don't think it will be used at all at CMU,
except by the one or two people who have been writing graphics code on
our Lisp machines and have somehow manged to figure this stuff out.
-- Scott
∂11-Dec-84 1207 DDYER@USC-ISIB.ARPA Re: Easy questions
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 11 Dec 84 12:07:22 PST
Date: 11 Dec 1984 12:02:13 PST
Subject: Re: Easy questions
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
Replies from:
8-Dec Kent M Pitman easy questions? (1327)
8-Dec John W. Peterson Re: Easy Questions (3632)
------
Date: 8 December 1984 19:54-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: easy questions?
Actually, the second question is quite hard. It's easy to say
"Oh, yeah, if you provided me a window system, I'd use it for ..."
without knowing what it offered because it's a "friendly" thing to
say and people will be willing to suppose your window system will
"meet their needs". Saying I wouldn't use a window system even
if you gave it to me is to say you don't believe it would meet your
needs no matter what, which either says you strongly believe that
there are two different viable theories of window systems and that
you want one but believe CL will provide the other, or that you
believe there's only one such system and CL doesn't stand a chance
in hell of going the right direction.
Anyway, it occurs to me that you might ammend the second question, or
add a third, to find out what features that if a window system lacked
would make it useless, or what features that if a window system had
would make it useless. eg, you might have said:
"What kind of window system would not suit some existing, under
development, or planned program?"
-kmp
Date: Sat 8 Dec 84 18:25:06-MST
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Re: Easy Questions
What existing, under development, or planned programs
would use common lisp's window system if it had one?
I'm currently working on a CAGD (Computer Aided Geometric Design) system under
lisp. It is extensivly window based, and designed to be portable to some
degree (versions currently run on devices such as Apollo domains and Evans &
Sutherland PS300 Vector engins). The system is "different" from most CAD
environments in that a program (a "procedural model") is written to describe
the part you are constructing. These programs "emit" B-Spline surfaces, which
are then used to generate shaded images, N/C toolpaths, etc. We use
interactive (3-Dimensional) graphics to view the model as it is constructed.
This is coupled with a special version of SETF that displays the graphics
representation of an entity (point, line, arc, curve, surface, etc) in a
graphics window when it's value is assigned. Multiple graphics windows can
be used to view differnt (or different views of the same) geometric
constructions. At any time you can grab a knob and rotate the geometry in
a 3D window to get a better view (this happens in real time on the E&S tubes,
step-by-step on less powerful displays).
Since the model is built from a lisp program, a text editor (usually a full-
featured EMACS) window is used to write the program in. You evaluate your
program step-by-step in the emacs window; and see the geometric results in
the graphics window as you go along.
A current (and very tricky!) research issue is to be able to interactivly
modify the graphics representation of the model (in the graphics window) and
have these changes reflected in your program. Thus, the textual representation
of the model in your EMACS window would get automaticly updated, much like
the graphics is updated now when you change the text. [A master's student
here has done some preliminary work with this].
Currently this is all done with, well, a lot of masking tape. We have a
PSL (Portable Standard Lisp) process running under the control of Gosling's
emacs. The PSL process in turn drives the several graphics windows, updating
them whenever a SETF occurs on a geometric object. In my ideal universe,
this would be running as a single Lisp program on a powerful Lisp Machine.
But these weren't readily available to us when we started (80-81), and
many of our contractors would still balk at an $80K/User workstation.
Hmmm, that's probably a longer discription than you bargianed for, but I guess
it's a useful example of a -complex- application for a Lisp-based window
system. After all, I want these windows to do everything from powerful
text editing to real-time 3D graphics...
PS
I would find a summary of the applications you here about interesting. And
as to your other question:
What existing, under development, or planned programs
would NOT use common lisp's window system, even if
it had one? Why?
About the only code I can think of that falls into this catagory are
ones that aren't interactive (i.e, rendering programs that take a long time
to run). But even then, I STILL want those windows for debugging and editing
it!
-------
-------
∂12-Dec-84 2201 RAM@CMU-CS-C.ARPA Easy Questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Dec 84 22:01:46 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 13 Dec 84 01:02:24-EST
Date: Thu, 13 Dec 1984 01:02 EST
Message-ID: <RAM.12071010731.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Dave Dyer <DDYER@USC-ISIB.ARPA>
Cc: cl-windows@SU-AI.ARPA
Subject: Easy Questions
I have a suspicion that the Hemlock text editor will not use any
window standard which may be agreed upon. Hemlock is currently in use
in the CMU community, and a much mutilated early version forms the
basis of the DEC VAX Lisp editor. It is about 20k lines of largely
portable Common Lisp code. The current Hemlock screen manager is
inadequate, and one of my current projects is to design a new one.
The main functions of the screen manager will be the following:
1] Allocate windows in a manner culturally compatible with EMACS.
2] Provide primitives for drawing strings and copying and clearing
screen areas.
3] Provide some sort of abstract interface to multiple fonts of
varying heights and widths. I have something in mind along the
lines of Scribe font-families.
4] Deal with demultiplexing keyboard and mouse input.
5] Provide some sort of abstract interface to the software interrupts
generated by our window system when windows are exposed or
resized.
6] Have some sort of support for highlighting.
Some reasons I don't think that a portable window manager is likely to be
usable:
A] Some of things that need low-level support in the window system
(4, 5) probably cannot be resolved to everyone's satisfaction.
B] Efficiency is important, thus it may be desirable to add special
primitives to make the drawing primities provided more closely
correspond to those actually supported.
Other comments:
I am not very impressed by environment query functions, or rather
the programming style they seem to encourage. Redisplay, which is the
level above the screen manger, needs to have a very good idea of what
the device can and cannot do. What I intend to do is have several
different versions of redisplay which are selected on the basis of the
general class of device driven, e.g. bit-mapped screen, windowing
terminal, smart terminal, dumb terminal. If it is necessary to have
significant procedural knowledge about the device at a level above the
window system to attain good performance across a wide range of
devices, it is futile for the window system to attempt to hide the
fundamental characteristics of the device.
If graphics includes such things as scaling, symbols, rotation and
arbitrary coordinate transforms, then I think that it is wrong to
think of "Windows" as being a layer above "Graphics". It is true that
any window system will be based on some set of graphical primitives
for doing things such as rasterop and drawing lines, but these things
will operate in device units, and thus will not be the primitives of
the graphics system. I suspect that it is much more probable that the
graphics system be built on the window system, since graphics will
probably be done on the windows or "virtual displays" provided by the
window system, while the window system will have no use for any of the
hair provided by the graphics package.
Rob
∂09-Jan-85 0110 DDYER@USC-ISIB.ARPA This space intentionally left blank
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 9 Jan 85 01:10:32 PST
Date: 9 Jan 1985 01:07:31 PST
Subject: This space intentionally left blank
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
I've been impressed by both the high quality and the low volume
of discussion on this mailing list. I think this is indicative
of an unfortunate state of affairs. We collectively appreciate
the nuaces of and appreciate the magnitude of "the window problem",
hence the high quality. We collectively agree on most issues of
substance, hence the low volume.
This would be fine, except there is no CL window system, and
at this rate, there never will be! Why this paralysis? I suspect
we also share the resigned realization that a combination of
vested interests and inertia will defeat any effort to establish
a standard.
-------
∂09-Jan-85 1001 KACZMAREK@USC-ISIF.ARPA Dire Dyer Prediction
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 9 Jan 85 10:01:43 PST
Date: 9 Jan 1985 08:02:54 PST
Subject: Dire Dyer Prediction
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>
To: cl-windows@SU-AI.ARPA
In-Reply-To: (Message from "Dave Dyer <DDYER@USC-ISIB.ARPA>" of 9 Jan 1985 01:07:31 PST)
I think that the dire Dyer prediction is premature.
I take the volume of messages for this group as a positive sign. It has
been considerably higher for this group than for the two other groups I
know about. The volume of messages has reduced lately indicating, as Dave
points out, agreement on the issues. (Should the volume be seasonally
adjusted? We have all probably had more vacation days/holidays recently
than normal.) I think any drop in volume indicates that we are at a
critical point--we are ready to start the process of design. I would
suggest that we need someone, preferably who already has a design for a
window system, to step forward and propose it as the standard. (If more
than one volunteer steps forward we ought to consider multiple proposals.)
Published proposals followed by a several day workshop to discuss them
seems appropriate to me.
The proposals are sure to cause controversy and vested interests are
certainly going to play a part in the negotiations that follow. Some
groups will decide not to follow the standard and others will. That is
nothing new. I don't think we ought to admit defeat just yet.
Tom
-------
∂09-Jan-85 1117 DDYER@USC-ISIB.ARPA Re: This space intentionally left blank
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 9 Jan 85 11:17:08 PST
Return-Path: <JW-PETERSON@UTAH-20.ARPA>
Received: FROM UTAH-20.ARPA BY USC-ISIB.ARPA WITH TCP ; 9 Jan 85 01:33:45 PST
Date: Wed 9 Jan 85 02:35:55-MST
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Re: This space intentionally left blank
To: DDYER@USC-ISIB.ARPA
cc: JW-Peterson@UTAH-20.ARPA
In-Reply-To: Message from "Dave Dyer <DDYER@USC-ISIB.ARPA>" of Wed 9 Jan 85 01:07:31-MST
ReSent-Date: 9 Jan 1985 11:16:59 PST
ReSent-From: Dave Dyer <DDYER@USC-ISIB.ARPA>
ReSent-To: cl-windows@SU-AI.ARPA, cl-graphics@SU-AI.ARPA
A related question. I thought (or at least was under the impression) that
I was tuned into the CL-GRAPHICS list as well. I have not heard a *peep* out
of that list, do you know if it's active?
This is somewhat relavent to CL-Windows, since I am from the school of thought
that the window system should know about (and perhaps be based on) the
graphics support. To some extent, I've been "waiting" to see what that list
says (This may hold true for others as well, e.g., the "units of measurement"
discussion a while back).
Cheers.
-------
∂09-Jan-85 1322 boetje@DEC-HUDSON here's something to make up for the long silence... Jerry
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 9 Jan 85 12:59:45 PST
Date: Wed, 09 Jan 85 15:10:33 EST
From: boetje@DEC-HUDSON
Subject: here's something to make up for the long silence... Jerry
To: cl-windows@su-ai.arpa, cl-graphics@su-ai.arpa
9 January 1985
COMMON LISP
Graphics Models
!
Page ii
CONTENTS
1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 1
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . 1
1.2 Terms . . . . . . . . . . . . . . . . . . . . . . 1
2 GENERAL CONCEPTS . . . . . . . . . . . . . . . . . . 2
3 COORDINATE SYSTEMS . . . . . . . . . . . . . . . . . 4
3.1 Application, World, User Coordinates . . . . . . . 5
3.2 Master, Object Coordinates . . . . . . . . . . . . 5
3.3 Physical Device Coordinates . . . . . . . . . . . 5
3.4 Logical Device Coordinates . . . . . . . . . . . . 6
3.5 Virtual Display Coordinates . . . . . . . . . . . 6
3.6 Normalized Device Coordinates (NDC) . . . . . . . 7
4 TRANSFORMATION . . . . . . . . . . . . . . . . . . . 8
4.1 Rotation . . . . . . . . . . . . . . . . . . . . . 8
4.2 Scaling . . . . . . . . . . . . . . . . . . . . . 8
4.3 Translation . . . . . . . . . . . . . . . . . . . 8
5 TRANSFORMATION OPERATIONS . . . . . . . . . . . . . 9
5.1 Matrix Representation . . . . . . . . . . . . . . 9
5.2 Window-Viewport Transformation . . . . . . . . . . 9
5.3 Active Transformation . . . . . . . . . . . . . 10
6 CLIPPING RECTANGLE . . . . . . . . . . . . . . . . 10
7 COMPOSITION . . . . . . . . . . . . . . . . . . . 11
7.1 Composition Space . . . . . . . . . . . . . . . 11
7.2 Segments . . . . . . . . . . . . . . . . . . . . 12
7.3 Virtual Display Composition . . . . . . . . . . 12
7.4 COMMON LISP Composition Levels . . . . . . . . . 13
8 ATTRIBUTES . . . . . . . . . . . . . . . . . . . . 13
8.1 Attribute Descriptions . . . . . . . . . . . . . 13
8.2 Attribute Inheritance . . . . . . . . . . . . . 16
9 VIRTUAL DISPLAYS . . . . . . . . . . . . . . . . . 17
9.1 Composition Space . . . . . . . . . . . . . . . 18
9.2 Picture Area . . . . . . . . . . . . . . . . . . 18
9.3 Banner Area . . . . . . . . . . . . . . . . . . 18
9.4 Border . . . . . . . . . . . . . . . . . . . . . 19
9.5 Margin . . . . . . . . . . . . . . . . . . . . . 19
9.6 Virtual Display Window . . . . . . . . . . . . . 19
9.7 Device Viewport . . . . . . . . . . . . . . . . 19
9.8 LISP Terminal Streams To Virtual Devices . . . . 19
9.9 Input Cursor . . . . . . . . . . . . . . . . . . 20
10 POINTING AND PICKING . . . . . . . . . . . . . . . 20
10.1 Pointing . . . . . . . . . . . . . . . . . . . 21
10.2 Picking . . . . . . . . . . . . . . . . . . . . 21
11 DISPLAY MANAGEMENT . . . . . . . . . . . . . . . . 21
11.1 Visibility And Stacking . . . . . . . . . . . . 22
11.2 Sensitive Regions . . . . . . . . . . . . . . . 23
11.3 Menus . . . . . . . . . . . . . . . . . . . . . 23
11.4 Pointer And Selection . . . . . . . . . . . . . 23
12 BITMAPS . . . . . . . . . . . . . . . . . . . . . 24
!
COMMON LISP Graphics Models Page 1
INTRODUCTION
1 INTRODUCTION
1.1 Purpose
This somewhat ambitious document is an attempt to establish a common
framework for discussions of graphics, windows, virtual displays, and
all the supporting concepts that go along with them. It specifically
doesn't define LISP functions yet. My claim is that without agreement
at the level of concepts and terminology, we can't possbly get started
on defining LISP functions.
The material presented here covers concepts and terms which properly
belong to both the graphics and windows committees. The reason for
this is to present a unified view toward video displays before we
define functions. I believe that when we start defining functions,
we'll find a fairly neat partition of functions between graphics and
virtual display creation and management. But we're less likely to
have functional incompatibilities if we can agree on some high level
ideas.
A section missing from this document is a discussion of levels of
capabilities that can be supported by various hardware and software
implementations. I'd welcome ideas on this. As a first cut, I'll
propose three levels:
1. That which you can do on a cell-oriented character terminal
such as a VT100 (text editor capabilities, multiple displays
and simple menus).
2. Add basic graphics operations but without composition. Level
2 might include restricted composition of virtual displays
(no additional scaling or rotation) much like the frame/pane
systems around.
3. Full multi-level composition capability and allowance for
user-written N-dimensional processing.
With some luck, this should start a new flood of discussion. Happy
reading.
1.2 Terms
Terms will be defined in this document by establishing the concepts
they represent. This will not only provide context and explanation
but show the functional interrelationships among the various terms.
Where possible, "established" terms will be used. A difficulty with
the current industry environment is that the same word (e.g.
"window") is often used to represent very different concepts. Such
industry discrepancies will be noted.
At least the following terms will be defined:
!
COMMON LISP Graphics Models Page 2
INTRODUCTION
Attribute
Clipping rectangle
Composition
Display management
Picking
Pointing
Segment
Transformation
Viewport
Virtual display
Window
The presentation of conceptual models is designed to explain and
illustrate both the generalization of certain techniques, such as the
window-viewport transformation, and the methods by which COMMON LISP
integrates the various objects and operations that support the
workstation.
2 GENERAL CONCEPTS
This paper deals with the concepts used in displaying data on a video
terminal. Such a display might be as simple as placing consecutive
lines of text on a screen. It might also involve drawing lines,
shading figures, and overlapping independent displays. This process
can be made arbitrarily complex. Certain conventions and techniques
have evolved for defining and managing this process. Unfortunately,
different conventions and terminology have evolved in the different
worlds of display management and graphics. Much of this paper
describes a system of terminology and concepts which attempts to unify
the different approaches taken by display management and graphics.
The remainder of this section will describe the display process in
general (and not always immediately defined) terms.
The basic displayable object is a "virtual display." This is a
rectangular area which can be associated with (made visible on) the
screen of a video display device. A virtual display can have a
"banner" (identifying information), a "border" (a pattern that
outlines the virtual display), a "picture area" (the inside of the
display where information can be shown), and up to four "margins"
(space between the border and the picture area).
The simplest kind of information display involves creating a virtual
display and writing text into its picture area by using the normal
COMMON LISP stream output operations.
The next level of complexity involves doing graphical operations to
the picture area of a virtual display. Graphical operations are those
which (loosely speaking) produce non-text images in the virtual
display. They include operations such as drawing lines and polygons,
filling areas with some pattern, and putting graphical symbols at
points.
!
COMMON LISP Graphics Models Page 3
GENERAL CONCEPTS
Graphical operations usually require one or more pairs of coordinates
to give the location(s) of the output. A virtual display's picture
area has a coordinate system with its origin (location 0,0) at the
lower left corner. The location of points in the picture area can be
given by specifying offsets into the picture area along the horizontal
(X) and vertical (Y) axes. These offsets, as well as the bounds of
the picture area, are expressed in centimeters.
All supported graphics operations can be done directly in a virtual
display, as long as the coordinates are restricted to those that fall
roughly within the bounds of the picture area. However, not all data
in the world falls numerically within the bounds of a picture area.
For example, a physicist might want to graph pion production rate vs.
impact energy in furlongs per fortnight. In order to present a visual
depiction, the data (in both axes) must be scaled and translated in
order to fit into the bounded coordinate system of a picture area. It
may also need to be rotated about some axis. This process is known as
"coordinate transformation." What is required is a method that defines
the appropriate transformation and thus allows the user to express his
data in the most convenient units. The commonly selected method is
called the "window-viewport transformation."
A "window" is a rectangular area usually specified in the coordinate
system of the user data. This user coordinate system is called the
"application data space." The specification of a window is really a
statement that says "all data of interest to me falls in this range."
A "viewport" is a rectangular area defined in the coordinate system in
which the graphical representation of the data will be kept or
displayed. Such a coordinate system might be that of a virtual
display, with the viewport defined to be all or part of the virtual
display's picture area. The specification of a viewport is a
statement that "this is where I want to see the pictorial view of my
data."
At the simplest level, a window-viewport transformation might involve
the definition of a window in a user's application data space and an
associated viewport which is the picture area of a virtual display.
Now the user is free to draw lines and do other graphical operations
in the coordinate system of his data. The results will appear in the
picture area of the virtual display.
Now that the transformation operation is defined, a further
complication can be introduced: the notion of "composition."
Composition means the building up of a graphical object in a separate
coordinate system (the "composition space"). In the previous case,
the picture area of a virtual display was used as a composition space.
There is no reason that the notion of composition cannot be combined
with transformation to enable production of arbitrarily complex
graphical systems. For example, the Graphics Kernel System (GKS)
defines two levels of composition and transformation. GKS comes with
a predefined composition space called Normalized Device Coordinates
(NDC) which has bounds at (0.0,0.0) and (1.0,1.0). The user first
!
COMMON LISP Graphics Models Page 4
GENERAL CONCEPTS
specifies a transformation from application data space into NDC. Then
additional transformations are created which map portions of NDC space
onto the physical device screen (which is treated as another
composition space).
This complexity can be increased since this process can go to any
level if the user is allowed to create independent composition spaces.
The graphics world has created the concept of "segments" to represent
independent composition spaces. These composition spaces are
typically mapped onto multiple viewports so that a single graphical
object may be viewed simultaneously in many places. For example, the
symbol for a NAND gate is drawn in an independent composition space
which is then mapped into multiple places in a circuit diagram.
"Display management" refers to the means supplied to position virtual
displays on the screen and to determine which shall be visible.
Virtual displays are made visible on the screen by associating them
with the screen. Since virtual displays are opaque, they can hide, or
"occlude," other virtual displays. The display management system must
therefore determine which virtual display will be occluded when two
overlap on the screen. The system does this by consulting the
"stacking order" to see when each display was associated with the
device. The position of a virtual display in the stacking order can
be altered, or the virtual display can be removed from the stacking
order altogether.
The display management system must also provide means to move virtual
displays on the screen and to change their shape and size.
A pointing system allows the user to move a cursor around the screen
in order to indicate positions where operations should take place or
to choose some object (such as a menu selection) from a display. The
positioning operation is called "pointing" and the process of using
the pointing system to choose an object is called "picking." Certain
areas of the display can be made sensitive to the pointing system's
cursor so that an action can be triggered when the cursor enters or
leaves the sensitive area.
With this introduction, the remainder of the paper goes on to more
rigorously define these and other concepts of a possible COMMON LISP
graphics and display model.
3 COORDINATE SYSTEMS
Much of the confusion around displays, graphics, bitmaps, etc. has to
do with the use of different coordinate systems and the
transformations between them. Several coordinate systems will be used
in later discussions. Some of the important ones are defined here.
!
COMMON LISP Graphics Models Page 5
COORDINATE SYSTEMS
3.1 Application, World, User Coordinates
These terms all loosely refer to the same idea of an unbounded,
N-dimensional space of floating-point numbers, where N is typically 2
or 3. As used in graphics systems, these terms really refer to the
coordinate system in which some particular set of graphical operations
(draw line, draw point, etc.) is performed. Another way of stating
this is that these are the most convenient coordinates in which a user
can graphically describe his data.
For example, for a graph of volume of sales by year, it's most
convenient for the user to give the data to the graphics system as
number pairs representing millions per year. The graphics system is
then responsible for eventually transforming this data to the
coordinates of the display device and displaying it.
There is no composition implied by the specification of several
graphical objects in overlapping application coordinates. For
example, several objects may be drawn in a range of coordinates from
(1.0,1000.0) to (5.0,1000.5) and yet they will not appear together in
the display if they are directed to different composition spaces.
All output operations are specified in application data space and are
transformed into a composition space. This implies that there can
only be a single "active transformation" in effect at any given time.
(See Transformation Operations for more information on the active
transformation.)
This paper will use the term "application data space" when referring
to the coordinate system in which the user performs the basic
graphical operations that build an object.
3.2 Master, Object Coordinates
These terms refer to the coordinate system defined by some composition
space used to describe a particular object. The coordinates are
expressed as floating-point numbers. This new object may be a part of
a larger drawing in one or more different composition spaces.
This paper will use the term "master coordinates" for coordinate
systems used in this way.
3.3 Physical Device Coordinates
Physical device coordinates consist of a bounded set of
two-dimensional integer coordinates that specify the addressable
positions of an output device's display area. The device coordinates
themselves do not specify the absolute size of an addressable unit.
The unit may be a pixel on a bitmap terminal, or a character cell on a
character terminal. Each implementation must supply functions which
!
COMMON LISP Graphics Models Page 6
COORDINATE SYSTEMS
give the physical size of the addressable units of the device, for
example, the height and width of a pixel. This allows users who wish
to work in the physical units of the device to scale their coordinates
appropriately.
The numeric range of each axis is defined by the physical device
itself, as are the location of the origin and the direction of the
axes. For example, a character terminal may have an origin at (1,1)
in the upper left corner of the screen with the X bound of 80 or 132
and the Y bound of 24. A particular bitmap terminal may have an
origin at (0,0) in the lower left corner with X and Y ranges of 767
and 468.
3.4 Logical Device Coordinates
Logical device coordinates are two-dimensional coordinates with
floating-point values. Logical device coordinates specify, in
centimeters, locations on a "logical device" which is independent of
the particular physical display device. Furthermore, logical
coordinates always have a (0,0) origin at the lower left corner of the
display screen. The logical display screen thus corresponds to the
upper right quadrant of a conventional X-Y coordinate system.
Since logical device coordinates always specify measurements in
centimeters, an object or display that is described using logical
device coordinates will have the same size and shape on any output
device. Users who wish to work in physical device coordinates can use
the functions that give the size of a physical device unit to control
the size and shape of their images. (See Physical Device Coordinates,
above.)
This paper will always use the term "device coordinates" in the sense
of "logical device coordinates" unless otherwise stated.
3.5 Virtual Display Coordinates
Virtual display coordinates are two-dimensional floating-point
coordinates that specify locations within a virtual display. The
units of the virtual display coordinates are the same as the units of
the logical device coordinates, that is, centimeters.
Since virtual display coordinates and logical device coordinates share
the same units and since both have origins in the lower left corner,
the position of a point in a virtual display on the logical display is
a pure translation of that point from the origin of the logical
display coordinate system. In other words, only translation is
required when placing or shifting a virtual display on the logical
device; no scaling or rotation is needed.
!
COMMON LISP Graphics Models Page 7
COORDINATE SYSTEMS
3.6 Normalized Device Coordinates (NDC)
This is a term commonly defined by the implementors of graphics
systems. Normalized Display Coordinates describe an idealized
graphics display device that has a square display and an aspect ratio
of 1 (meaning that a mathematical square is "displayed" as a square,
not a rectangle). Locations in this display are specified by
coordinates whose X and Y values can be floating-point numbers in the
range of 0.0 to 1.0, inclusive. The origin in the NDC system is at
the lower left of the display.
By using Normalized Device Coordinates, all graphics data is mapped
into NDC space before mapping to the physical device. In the Graphics
Kernel System (GKS), NDC space provides both a device-independent
coordinate mapping and a graphical composition layer.
!
COMMON LISP Graphics Models Page 8
TRANSFORMATION
4 TRANSFORMATION
Transformation (or coordinate transformation) is the one-to-one
mathematical mapping of points in one coordinate system to those in
another. In the current context, transformation is limited to linear
operations of scaling, rotation, and translation. Projection (mapping
of an N-dimensional space onto N-1 or fewer dimensions) is not treated
in this document. The remaining discussions are therefore limited to
two dimensions, although nothing in the design should prohibit a user
from defining N-dimensional transformations and implementing his own
projection algorithms for treating higher dimensional graphics.
See Chapter 7 of "Fundamentals of Interactive Computer Graphics"
(Foley and Van Dam) for a thorough discussion of coordinate
transformations in graphics systems.
4.1 Rotation
Rotation is the mapping of points (x,y) to points (x',y') by the
equations
x' = x * cos(a) - y * sin(a)
y' = x * sin(a) + y * cos(a)
where a is the angle of counterclockwise rotation. Visually, the
entire picture is rotated by the angle a. Rotation is always computed
around the coordinate origin. Aspect ratio is always preserved under
a rotation transformation.
4.2 Scaling
Scaling is a mapping of points (x,y) to points (x',y') by the
equations
x' = x * x←factor
y' = y * y←factor
where x←factor and y←factor are constant terms. Visually, scaling
produces an enlargement or diminishment of the plotted data along
either axis. Aspect ratio (the ratio of the sizes of the x and y
axes) is preserved only when x←factor = y←factor.
4.3 Translation
Translation is the mapping of points (x,y) to points (x',y') by the
equations
!
COMMON LISP Graphics Models Page 9
TRANSFORMATION
x' = x + x←offset
y' = y + y←offset
where x←offset and y←offset are constant terms. Visually, the entire
picture is moved intact to another location.
5 TRANSFORMATION OPERATIONS
5.1 Matrix Representation
All points in the graphics system are represented in homogeneous
coordinates. Therefore, all transformations in N-dimensional space
may be represented by an (N+1)-dimensional square matrix. The actual
mapping of points (x,y) to points (x',y') may be carried out using the
following equation:
[x', y', 1] = [x, y, 1] * | r11 r12 0 |
| r21 r22 0 |
| t1 t2 1 |
which reduces to two equations involving a total of four multiply and
four add operations.
Transformations in COMMON LISP will be treated as LISP objects which
may contain these specialized N-dimensional matrices. A
transformation object can be created by specifying a window-viewport
pair and adding rotation information, if any. The user will also be
allowed to create transformation objects to suit his own needs. This
latter capability is important, since the window-viewport
transformation only produces scaling and translation without any
rotation capability. Also, the transformation manipulation functions
will accept N-dimensional transformation objects and are likely to be
more efficient than user-written matrix multiplication code.
A transformation object may also be defined which involves a
user-written function that will be called when a transformation is
required. This feature may be used to allow users to write
3-dimensional projection and clipping transformations.
5.2 Window-Viewport Transformation
A window is a rectangle whose limits (vertices) are defined in a set
of coordinates which may lie in application data space or in some
defined composition space. Conceptually, a window functions like a
"window" in the real world (the glass variety). It opens a
rectangular area in some coordinate space so that any data which falls
within the limits of the window may be made visible to the user. A
window may specifically delete data that falls outside its limits; in
this case it is a clipping rectangle (see Clipping Rectangle, below).
If clipping is not enabled, data that falls outside the window may
!
COMMON LISP Graphics Models Page 10
TRANSFORMATION OPERATIONS
still be visible.
In conjunction with a viewport, a window is used to provide a scaling
and translation transformation. This is a conventional method in
graphics to specify a coordinate transformation.
A viewport is a rectangle whose limits are defined in a coordinate
system that must lie in some defined composition space. The viewport
serves two functions:
o It defines where in the composition space the data or other
information will appear.
o When associated with a window, it defines a coordinate
transformation specification and also indicates that data
"seen through" that particular window will appear in the
viewport.
5.3 Active Transformation
All graphics operations must be applied with respect to some
transformation. For example, a line is drawn by specifying the end
points of the line. The coordinates of these points may be
transformed into the master system of some object which is being used
in a composite display, or directly into the picture area of a virtual
display. In the first case, the transformation may be an elaborate
one which includes multiple levels of scaling and rotation. The
latter may only involve a simple translation of points relative to the
origin of the logical device coordinates.
All of the output functions which require positioning information,
such as line drawing and character insertion, will take an optional
transformation argument. The default value of this argument will be
the currently specified active transformation. The active
transformation is no different from any other transformation except
that it has been designated to be the default transformation for
output operations. The system should provide a function similar to
the COMMON LISP IN-PACKAGE function which sets the value of a special
variable which is the active transformation. In addition, the system
may have a macro (WITH-TRANSFORMATION) which binds the value of the
current transformation within some scope.
6 CLIPPING RECTANGLE
A clipping rectangle is a rectangle defined as a window either in
application data space or in a composition space. Clipping is part of
the transformation operation. It is usually done in the originating
coordinate system. The purpose of clipping is to remove from the
display any portions of a graphical image that lie outside the
clipping rectangle. Thus, if the user specification of a line has end
!
COMMON LISP Graphics Models Page 11
CLIPPING RECTANGLE
points which are outside the rectangle and clipping is enabled, only
the portion of the line that falls within the rectangle will be mapped
onto the destination composition space. If clipping is not enabled,
the entire line will be mapped.
In the destination coordinate system, clipping is performed only at
the boundaries of the physical device. (A viewport cannot define a
clipping rectangle.) Since physical device coordinates are a bounded
coordinate system, any points which lie outside the bounds of the
physical device will be unconditionally clipped.
Clipping can be enabled or disabled on a global basis or for each
graphical output operation.
7 COMPOSITION
Composition is the process of building complex graphical objects from
(potentially) a number of different objects and coordinate systems.
Conceptually, composition is akin to placing various graphical objects
onto some flat surface in a particular arrangement. This flat surface
is termed a composition space. Windows can then select portions of
this flat space either for viewing on the screen or for use in other
composition spaces.
A simple example of composition is the definition of the symbol for a
NAND gate. The symbol is created in its own master coordinates. It
is then mapped onto various parts of another composition space and
lines are drawn using a different transformation into that composition
space to connect the symbols into a circuit diagram.
7.1 Composition Space
A composition space is an independent data space which has certain
special characteristics:
o It can store graphical objects.
o It can optionally define a rectangle which may be used
simultaneously as a window, a viewport, and a clipping
rectangle.
Mapping from application data space or from a composition space onto
another composition space is accomplished by specifying either a
window-viewport pair (plus rotation) or by explicitly providing source
and destination spaces plus a transformation matrix and a clipping
rectangle.
Portions of a composition space can be further mapped onto other
composition spaces to an arbitrary depth; and composition spaces can
be recursively mapped to themselves. When a composition space is
!
COMMON LISP Graphics Models Page 12
COMPOSITION
mapped onto other composition spaces, changes made in the original
composition space appear in all the composition spaces it is mapped
onto. By contrast, the contents of a composition space can be copied
to other composition spaces. Any subsequent changes made in the
original composition space will not be reflected in the copies.
7.2 Segments
"Segment" is a term used in conventional graphics systems to denote an
independently specified graphical object. Segments are built in
independent composition spaces. Segments may be used together with
other graphical objects and primitive operations to create a more
complex graphical object.
The creation and use of segments is entirely analogous to the
segmentation of programs into subroutines which may be used repeatedly
by different code segments. The building process is not confined to a
single level. Segments may be composed of other segments and the
entire object then used as a portion of a larger diagram. The
graphics system handles the nested coordinate transformations
necessary to produce the levels of graphical object.
A significant feature of a segment is that it is created once and may
then be mapped (via additional transformations) any number of times
into different composition spaces. An example of a segment is the
symbol for a NAND gate. This symbol need only be defined once. It
can then be mapped any number of times to create a circuit diagram.
Note that if the original NAND gate symbol is changed, all the
mappings of it automatically change. Furthermore, any change to a
transformation between one space and another propagates into any
further mappings. For example, if the window surrounding the NAND
gate segment is made larger, the NAND gate will appear to shrink in
each viewport mapped to that window. The graphics system handles all
intermediate levels of coordinate transformation needed to map the
segments.
Segments may be copied rather than mapped, in which case they lose
their reference to the original object. Changes in the original will
not affect any copies made from it.
Segments may be returned as the result of a pick operation (see
Pointing and Picking).
7.3 Virtual Display Composition
Since virtual displays are themselves composition spaces (see Virtual
Displays), they can be mapped onto other composition spaces. This is
particularly useful when making a virtual display that is a composite
of other virtual displays. Such a composite display can be treated as
a single display for display management purposes, and yet each display
!
COMMON LISP Graphics Models Page 13
COMPOSITION
can retain its own identity for all other operations. Some systems
call this a "pane" system with the final composite display called a
"frame."
7.4 COMMON LISP Composition Levels
COMMON LISP should allow for creation of arbitrary levels of
composition. One that will be provided by default is:
o Virtual display space (allowing virtual displays to be mapped
into the picture area of another virtual display)
8 ATTRIBUTES
Attributes are parameters that affect the visual representation of
output operations. They can, for example, determine the background
color of a composition space, the width and pattern of a line, the
font and spacing of text, or the visibility of a graphical object
mapped onto some composition space.
Some attributes are inherently "static" while others are inherently
"dynamic." When dynamic attributes are changed, the visual results of
previous operations that used those attributes will immediately
change. Operations done with static attributes must be re-executed in
order to change the visual appearance of their results.
Some attributes are naturally associated with types of operations
(such as graphics primitives) while others are associated with objects
(such as composition spaces). Some can be associated with both
objects and operations. For example, a composition space can have an
attribute that specifies the default color of all operations that take
place within it, and an individual graphics operation can specify a
color attribute to override the default.
Attributes are also organized in blocks. (GKS calls attribute blocks
"bundles.") Attribute blocks can be associated with individual
operations, transformations, or composition spaces. Nesting of
transformations implies some form of attribute nesting as well.
8.1 Attribute Descriptions
Attributes can be categorized by the type of operation or object they
affect, although this categorization is more for conceptual
convenience than to suggest a meaningful difference between the
attributes. The following is a suggested list of categories for
COMMON LISP attributes:
Composition space
!
COMMON LISP Graphics Models Page 14
ATTRIBUTES
Graphics
Text
Attributes associated with a composition space serve two functions:
they describe attributes of the composition space itself, and they
also provide a complete set of default attributes for any graphics or
text operations done into that space. These defaults can be
overridden by attributes applied to individual graphics or text
operations.
The following possible attributes which will be considered for
inclusion in a possible COMMON LISP graphics model are listed under
the categories described above. These attributes are all described in
terms of bitmapped terminals. Some of the attributes may function
differently - or not function at all - on other types of terminals,
such as character terminals. The specific behavior of each attribute
on various terminals is implementation-dependent.
o Composition Space Attributes - the first two attributes
determine characteristics of the composition space itself,
while the second two establish defaults for graphics or text
operations done in the space.
- Visibility - specifies whether operations done into this
space (when it is mapped into some other composition
space) will be immediately visible or deferred until a
later time.
- Background Color - specifies the background color of the
composition space.
- Drawing Color - specifies the default color to be applied
to all output operations into this space.
- Writing Mode - specifies the relationship applied to an
output operation and the existing bitmap pattern to
produce the resulting display rendition:
NIL - operation is performed (information is kept in
the display list) but the output display is not
changed.
:XOR, :OR, :ORC1, :AND, :ANDC1 - the Boolean
operation that is applied to the bitmap pattern of
the operation and the existing bitmap pattern to
produce the displayed result. The C1 forms mean
that the bitmap produced by the operation is first
complemented before the logical operation is
performed with the existing bitmap.
:REPLACE, :COMPLEMENT-REPLACE - the result of the
operation (or its complement) completely replaces
the affected contents of the display.
!
COMMON LISP Graphics Models Page 15
ATTRIBUTES
:ERASE, :COMPLEMENT-ERASE - the result of the
operation is completely replaced with the background
color (or its complement) of the composition space
o Graphics Attributes - these attributes are associated
specifically with graphics operations. They can also be
applied to a composition space to determine defaults for
graphics operations in that space.
- Line Width - specifies the width of a displayed line
expressed as a (floating-point) multiple of the minimum
width that the device can draw.
- Line Style - specifies the particular visual style of the
line to be drawn. The following are suggested although
implementations may vary in the types available:
:SOLID
:DASHED
:DOTTED
:DASHED-DOTTED
- Fill - specifies whether or not objects are to be filled,
the fill pattern to use, and the fill reference point.
- Marker Symbol - specifies the visual symbol used by the
graphics operations which place marker symbols at points.
The symbol is centered on the specified point. Supplied
symbols are implementation dependent.
o Text Attributes - these attributes are associated
specifically with text operations. They can also be applied
to a composition space to determine defaults for text
operations in that space.
- Font - specifies the font set to be used when writing
text. Values are implementation dependent.
- Character Spacing - alters the normal spacing of
character writing. This attribute is expressed as a
floating-point number that is multiplied by the character
height to produce additional space to be inserted between
characters. The number can be negative, in which case
characters may be forced closer together or overlapped.
- Character Slant - slants fonts to produce italics. The
slant is expressed in degrees and should be in the range
of -45 to +45.
- Base Line Angle - specifies the angle of writing
characters. This attribute is expressed as a
floating-point number representing degrees of rotation
from the normal horizontal. Unslanted characters will
!
COMMON LISP Graphics Models Page 16
ATTRIBUTES
always appear to be vertical when viewed from an angle
parallel to the base line.
- Text Path - specifies the direction of character writing
in relation to the base line. There are four possible
values:
:FORWARD - this is the normal left-to-right display
of characters in a direction parallel to the base
line.
:BACKWARD - this is the reverse of the :FORWARD
direction and is used, for example, when writing
Hebrew text.
:UP - characters are displayed sequentially "above"
each other in relation to the base line.
:DOWN - the reverse of :UP; characters are displayed
sequentially "below" each other in relation to the
base line.
- Texture - a bitmap pattern which is logically ANDed with
a character bitmap before writing to the display.
An implementation is free to designate supported attributes and to
categorize any supported attributes as static or dynamic.
8.2 Attribute Inheritance
Every composition space has a default attribute block associated with
it. This block must contain a complete specification of all the
supported attributes for an implementation. In general, these
attributes may be overridden on a per-operation basis.
A set of operations into some composition space may be performed with
respect to some other attribute block. This block may be incomplete.
Any required attribute values will be taken either from an explicit
value in a specific operation or from the default attribute block.
Attribute inheritance in the presence of multiple levels of
composition is not well understood. Static attributes may be treated
easily since the visual results of a performed operation cannot be
changed without re-executing the operation. Proper inheritance of
dynamic attributes, however, is more difficult to determine. At this
point, the inheritance of dynamic attributes is implementation
dependent.
!
COMMON LISP Graphics Models Page 17
VIRTUAL DISPLAYS
9 VIRTUAL DISPLAYS
A virtual display is a specialized graphical object used to display
graphics or text information on a physical device. It is the only
type of graphics object which can be displayed on a device.
A virtual display is made visible on a device by associating it with
that device, although a virtual display can exist without being
associated with any device. Associating a virtual display with a
device is similar to, but not the same operation as, creating a
mapping from one composition space to another. A major difference is
that virtual displays are opaque; that is, the order of association
affects the visible result on the device. If two virtual displays
overlap on the screen, the portion of the first which is overlapped by
the second will not be visible. Normal mappings onto composition
spaces are transparent, that is, all operations are always visible
(see Display Management).
Creation of a virtual display creates a composition space onto which a
number of graphical objects are mapped. These objects have default
spatial relationships which can be altered at the time the virtual
display is created. The following diagram illustrates the objects of
a virtual display in a typical configuration. All objects except the
picture area are optional.
Banner +--------------------------+
area | Banner area |
origin->+--------------------------+
============================<--+
= = |
= +----------------------+ =<--Borders
= | | =
= | Picture area | =
= | | =
= | | =
= | Picture area | =
= | origin | =
= |/ | <--Margins
= +----------------------+ = |
= <--+
+->+===========================
|
Virtual display origin
Each of the objects shown will be discussed in greater detail later in
this section.
The mapping of a virtual display's objects into its composition space
produce transformations which can be used during I/O operations.
Additional arbitrary transformations into this composition space can
be created as needed.
!
COMMON LISP Graphics Models Page 18
VIRTUAL DISPLAYS
To create a virtual display, one specifies the size of its picture
area along with the size and spatial relationship of any optional
parts. The total size of the virtual display is the size of the
picture area as extended by the optional parts.
9.1 Composition Space
The creation of a virtual display results in the creation of a
composition space within which the virtual display is built. This
space may be used in all respects as any other composition space;
users can do arbitrary graphical operations within it.
9.2 Picture Area
The picture area of a virtual display is the rectangular area where
data is normally displayed. It is a window-viewport pair which maps a
portion of application data space into the composition space of the
virtual display. The size of the viewport is the size specified when
the virtual display was created. By default, the window is the same
size and has the same coordinate system as the viewport; thus, the
transformation is trivial. A different window may be specified when
the display is created. Unless otherwise specified, the picture area
viewport has a coordinate origin at the lower left corner and a size
expressed in virtual display units (centimeters). The picture area
has a transformation object which may be used as the active
transformation in any graphics operation.
The other objects of a virtual display are placed in a fixed spatial
relationship to the sides of the picture area. If the picture area
grows or shrinks, the margins, border, and banner area move on the
screen to maintain this relationship.
9.3 Banner Area
The banner area is an optional part of a virtual display. It is
similar to the picture area in that it is defined as a window-viewport
pair. The viewport is mapped into the composition space in a
particular spatial relation to the picture area. It may be above,
below, or to the right or left of the picture area. It is separated
from the picture area by the width of the margin and border. Unless
otherwise specified, the banner area viewport has a coordinate origin
at the lower left corner. Its width (or height if the banner is to
the right or left) is, by default, the width (or height) of the
picture area viewport plus the width of any margins and borders. The
banner area has a transformation object which may be used as the
active transformation in any graphical operation.
!
COMMON LISP Graphics Models Page 19
VIRTUAL DISPLAYS
9.4 Border
A virtual display may optionally have a border. The border is an
outline of the picture area, separated from the picture area by the
margins. Its width is specified in virtual display units. In its
most basic form, the border may be a line of some default width
surrounding the picture area. If supporting hardware permits, it may
have an arbitrary thickness and tile pattern (see Bitmaps). The
border may be designated as a sensitive area for the pointing system.
9.5 Margin
The margin is the space between the border and the picture area; there
can be four margins associated with a virtual display. Its size is
measured in virtual display units. The default size of any margin is
implementation dependent.
Margins are most often used to separate text from the border.
However, some set of implementation dependent operations may also be
performed in the margins of a display, such as drawing lines for
scroll bars. The margins lie outside the coordinate system of the
picture area; they must be accessed by using the coordinate system of
the virtual display composition space.
9.6 Virtual Display Window
The entire rectangle encompassing the picture area, banner, border and
margins of a virtual display is enclosed in a window in the virtual
display composition space. This window may be used to map the display
onto a physical device or into some other composition space. The size
of this window tracks the "size" of the virtual display, such that if,
for example, the picture area viewport is changed, the virtual display
window is automatically adjusted.
9.7 Device Viewport
A device viewport is a specification, in logical device coordinates,
of the size and location of a virtual display on a physical device.
Unless otherwise specified, the size of a device viewport is the same
size as the virtual display window. The transformation is then a pure
translation. An arbitrary transformation may be applied to scale and
rotate the appearance of the virtual display on the screen.
9.8 LISP Terminal Streams To Virtual Devices
A virtual display may be used as an argument to the various varieties
!
COMMON LISP Graphics Models Page 20
VIRTUAL DISPLAYS
of MAKE-STREAM functions that exist in COMMON LISP. Such a stream can
be input, output, or both. A virtual display stream opened for output
means that printed LISP output will be directed to that virtual
display. An input stream designation means that a LISP read operation
on that stream will get input from the keyboard device attached to the
terminal. An input-output stream reads characters from the keyboard
and echoes those characters in that virtual display. All designation
of font, spacing, color, etc. is specified in attribute blocks
associated with that virtual display.
The physical device need not be a keyboard, although that is the
normal device. It may be any device capable of responding correctly
to the COMMON LISP input operations. This allows, for example, a file
to be associated with one display and the keyboard with another. The
resulting effects on the screen (and to the program) depend only on
the choice of virtual display used in the input operation.
9.9 Input Cursor
Each virtual display which has an associated virtual input device will
have an input cursor defined. The nature of this cursor is
implementation dependent but it must at least provide an indication,
when this display is being used for input, of the current location
where echoed input will appear. This cursor is often distinct from
the pointing (or mouse) cursor.
10 POINTING AND PICKING
In a virtual display and graphics environment, it is often necessary
to translate a visually perceived location on the display device into
information useful to the running program. Operations such as
selecting an item from a menu, indicating a virtual display to bring
to the top of the stacking order, and selecting a gate connection in a
circuit diagram are all examples of pointing or picking.
Pointing and picking are input operations that require a certain level
of physical device support. The device must be capable of generating
a visual indicator (cursor) which indicates a screen position, and it
must have a means of manipulating the position of this indicator. The
manipulation need not be independent from the host processor. For
example, the arrow keys on a character-oriented terminal might be used
to request the host processor to move the cursor to different spots on
the screen. Other supporting devices can be various forms of mouse,
light pen, tablet and cross-hair.
The distinction between pointing and picking is in the nature of the
object returned as a result of the operation. The result of a
pointing operation is always an N-dimensional (usually 2) coordinate.
The result of a picking operation is a previously defined graphical
object. This might be a simple object such as a line or it might be a
!
COMMON LISP Graphics Models Page 21
POINTING AND PICKING
composition space which makes up a part of the display.
A pointing or picking operation is always performed with respect to
some transformation. This transformation is used to specify both the
coordinate system in which the results are expressed and the level of
detail required of the operation. For example, a pick might return a
particular mapping of a NAND gate symbol, the NAND gate composition
space, or a portion of the NAND gate symbol, depending on the chosen
transformation.
Both pointing and picking are primarily input operations but may also
involve placement of the position cursor using the appropriate
coordinate system. The input operations are completed in a
device-dependent fashion, such as clicking a mouse button or pressing
a function key on the terminal.
Rectangular sections of the screen can be made sensitive to the
pointing cursor. Section 11.2 discusses this concept.
10.1 Pointing
Pointing is an input operation that returns a coordinate in some
N-dimensional space. The space must be previously defined. For
example, the coordinate may be an X-Y pair of physical device
coordinates. It may also be a coordinate in the master coordinate
system of some defined graphical object.
10.2 Picking
Picking is an input operation that returns a previously defined
graphical object. Such an object might be an entire virtual display,
for instance, when selecting a display to bring to the top of the
stacking order. It might also be some component of a graphical
object, such as a point, a line, or a segment.
11 DISPLAY MANAGEMENT
"Display management" refers to the facilities available for
controlling the appearance of the physical screen and making virtual
displays visible to the user. Since virtual displays are opaque when
placed onto a physical screen, they behave like cards stacked on a
table. Portions of the screen that are covered by the rectangle of a
virtual display are not visible while that display is visible. Thus,
a virtual display may hide (or "occlude") portions of other virtual
displays which were already on the screen. The display management
system must have the capability to place virtual displays on the
screen and remove them from the screen. The system must also be able
to move virtual displays on the screen and change their stacking
!
COMMON LISP Graphics Models Page 22
DISPLAY MANAGEMENT
order.
Other display management capabilities arise from the necessity to
provide a flexible and powerful user interface. Since the display
system should have some type of pointing device, the display
management system must allow the programmer to define all or portions
of a virtual display as being sensitive to the pointing device. This
means the the user's software can detect whenever the pointing device
enters or leaves some selected area of a virtual display. The system
must also provide for normal terminal I/O to be performed to and from
a virtual display.
11.1 Visibility And Stacking
A virtual display is a graphical object which may become visible on a
terminal screen. It can exist without being associated with any
device or it may be associated with several devices simultaneously.
The display management system remembers the order in which displays
are associated with each device. Associating several displays with a
device is called "stacking" since it is analogous to stacking up cards
on a flat surface; the order in which displays are associated with a
particular device is called that device's "stacking order." The
position of a display in the stacking order can be altered. It can be
brought to the top, pushed to the bottom, or placed above or below
another virtual display in the stacking order. If a display is moved
on the display screen, it maintains its position in the stacking
order.
The stacking order is important to the appearance of the screen,
because it helps determine which displays can hide other displays. A
virtual display is said to be "occluded" on some device if it is
beneath another virtual display in the stacking order for that device
and if some or all of its area is within the screen area occupied by
the other virtual display.
A virtual display, in addition to being associated with a device, may
also be "exposed" (rendered visible) or "unexposed" (rendered
invisible) on that device. In order for a virtual display to be
visible to the user on some device, it must be associated with that
device, be exposed, and not be entirely occluded by other exposed
virtual displays. A display can be made invisible but preserve its
position in the stacking order by making it unexposed. In this state,
it cannot occlude other virtual displays.
Exposure is a property of an element (virtual display) in a particular
stacking order, not a property of the element itself. Since each
display device has its own stacking order, a display may be associated
with more than one device but be exposed on only some of the devices.
!
COMMON LISP Graphics Models Page 23
DISPLAY MANAGEMENT
11.2 Sensitive Regions
Rectangular areas of a virtual display may be made sensitive to the
pointing device. A sensitive region is defined in virtual display
coordinates by specifying the lower left corner and the height and
width of the rectangle.
Designating a region as sensitive provides the programmer with several
capabilities for creating a user interface to the display system:
o The visual appearance of the sensitive region can be altered
either automatically when the pointing device enters or
leaves the region, or under program control without the
pointer moving at all.
o A LISP function can be invoked asynchronously when the
pointing device enters or leaves the region.
o The sensitive region can be returned as the result of a user
selection among a list of sensitive regions.
11.3 Menus
All display management systems should provide for a special type of
virtual display called a "menu." There can be many types of menus, but
one kind should be provided with all Common LISP systems. This is a
simple choice menu. The display appears as a vertical list of
options. The pointing device is used to point to a desired item and
the item is selected in an implementation-dependent fashion. There
must be LISP functions which allow the programmer to create the menu
(providing both the selectable items and the value to be returned from
selection of each item) and to display the menu and query the user for
an item selection. All of the usual display management functions
operate correctly on menus.
11.4 Pointer And Selection
Each implementation must provide a method for the user to "point" at a
particular location on the physical screen. This might be implemented
with a mouse, light pen, cross hairs, or the cursor movement keys of a
simple video terminal. This pointer should be able to indicate all
visible areas of the screen.
There must be a defined method of indicating to the display system
that some selection has been made relative to the pointing device.
The most common of these is the buttons on a mouse. It may also be
one or more special keys on the keyboard of the terminal device. Each
implementation must define the number of selection possibilities and
the method for invoking each.
!
COMMON LISP Graphics Models Page 24
DISPLAY MANAGEMENT
Each implementation must also provide some way of indicating that the
pointing device has moved.
12 BITMAPS
Many video terminal devices operate by allocating fixed-sized blocks
of display space (cells) for display of character and graphical data.
These cells are individually addressable and are the smallest
addressable unit from the programmer's perspective. Other graphics
devices are capable of doing direct vector and other graphic
operations on the display. Bitmapped terminals allow the programmer
to access individual pixels in the display directly. The method of
access is to maintain a two-dimensional array of bits in memory that
directly controls the display of each pixel. The array is called a
bitmap. All operations to the terminal display are made by altering
the bitmap.
In any implementation that supports bitmapped devices, each virtual
display will have a bitmap and each device will have a device bitmap.
It will be possible to retrieve all or portions of any of these
bitmaps via implementation-supplied functions as well as to create
bitmaps as LISP objects. Functions will exist to do arbitrary
operations combining bitmaps (OR, AND, etc.). These operations are
not clearly defined at this time. Suggestions appreciated. The
purpose of such bitmap operations is to provide special visual effects
such as shading and texturing.
∂09-Jan-85 1420 @MIT-MC:Henry%MIT-OZ@SCRC-RIVERSIDE Silence breaker
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 9 Jan 85 14:19:18 PST
Received: from MIT-APIARY-3 by MIT-OZ via Chaosnet; 9 Jan 85 17:17-EST
Date: Wed, 9 Jan 85 17:17 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-RIVERSIDE.ARPA>
Subject: Silence breaker
To: Cl-Windows@SU-AI.ARPA, Cl-Object-Oriented-Programming@SU-AI.ARPA,
Cl-Graphics@SU-AI.ARPA
As some of you may know, I am working on a kit for building menu-driven
graphical interfaces [such as document illustrators, circuit diagrammers,
etc.] called EzWin. The kit provides protocols for representing menu commands as
objects, mouse sensitivity and selection of graphical objects. It also tries to
separate the functionality of commands from the interface techniques and allow
alternative interaction styles. It is at a level considerably above the "just
bits on the screen" one at which Boetje@Dec's proposal is aimed, but would be
complementary to such proposals. A wide range of interesting graphical interfaces
is easily specifiable using this approach. I hadn't designed it with a "language
standard" in mind, but perhaps standardizing things at this level as well might
productive, promoting portability of interfaces.
I am currently preparing a paper on it for SigGraph '85. Interested people can
send me a message with US Mail address for a copy. It is too long for
transmission on this list and has many pictures.
∂20-Mar-85 2048 DDYER@USC-ISIB.ARPA ANSI windows
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:48:16 PST
Date: 20 Mar 1985 20:44:48 PST
Subject: ANSI windows
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
This tidbit is forwarded from WORKS digest
From: lef@nlm-vax.ARPA (Larry Fitzpatrick)
Subject: Alleged push for ANSI windows standard
Date: 5 Mar 85 23:28:58 GMT
Back in December, PC Week ran an article stating that several
companies(*) were banding together to push for a standard
"graphically oriented windowing environment". Standard, that is, for
the developer. My understanding (my need, in any case) is that this
would provide a basic functionality for manipulating windows, etc. so
that the developer of an application would not have to get involved
with the low-level screen manipulation.
I have heard of several packages that would act in this manner, some
of which are "coming soon" others which are out of reach(**, with the
possible exception of ALYS from Applix), none of which seem to come
close to being portable, let alone standard.
Does anyone know of:
a) any activity in this area by the companies in *?
b) any activity in this area by anyone not previously mentioned?
* - Microsoft, DRI, Intel, Apollo, Masscomp, Sun Micro Sys, Olivetti,
Motorola, Nova Graphics
** - Apple's Toolkit-32; GEM; ALYS from Applix; W/X/V packages from
groups at MIT and Stanford; does SunWindows fit the bill?; LOOPS?
-fitz
lef@nlm-vax
-------
∂20-Mar-85 2113 DDYER@USC-ISIB.ARPA ANSI windows (II)
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 21:13:22 PST
Date: 20 Mar 1985 21:10:51 PST
Subject: ANSI windows (II)
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA
This information forwarded from WORKS digest
From: oblio!jon@topaz (Jon Steinhart)
Subject: Information on the ANSI windows work
Date: 9 Mar 85 22:41:01 GMT
ANSI X3H3 has formed a subgroup to investigate a possible window
standard. The group is currently examining various proposals to
determine what areas a window standard would address. The subgroup
chair is John Butler from Microsoft.
The best way to keep informed about the work on windows is to join
ANSI X3H3. Contact Barry Shepherd at IBM in Austin. Annual fees are
around $75. Don't expect the committee to magically "meet your
needs" and "do the right thing" without your help and input.
Jon Steinhart
Counterpoint Computers, Inc.
ANSI X3H3
-------
∂29-Jul-85 1235 Fischer.pa@Xerox.ARPA RE: Clearing the screen and other such things.
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 12:34:34 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 29 JUL 85 12:33:27 PDT
Date: 29 Jul 85 12:30 PDT
From: Fischer.pa@Xerox.ARPA
Subject: RE: Clearing the screen and other such things.
To: Common-lisp@SU-AI.arpa
cc: CL-windows@SU-AI.arpa
Message-ID: <850729-123327-2607@Xerox>
Its pretty clear that the CL-Windows group became disheartened when it
was reported that ANSI was working on a standard. This may not be the
case. One can hope it was actually a mass defection to the ANSI group,
but I doubt that.
Perhaps now that the subjec thas been warmed up to, and since not much
seems to have solved the problem in the interim, perhaps we can get
someone to describe what the state of the various "standards committees"
are.
There were two mentioned just before the CL-Windows group closed its
shutters, one was a band of rowdy manufacturers (including Microsoft,
DRI, Intel, Apollo, Masscomp, Sun Micro Sys, Olivetti, Motorola, Nova
Graphics) the other of couse ANSI.
Can anyone comment immediately on the state of these committees to the
CL-windows@SU-AI.arpa mailing list?
(ron)
∂29-Jul-85 2307 DDYER@USC-ISIB.ARPA Clearing the screen etc.
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 23:07:02 PDT
Date: 29 Jul 1985 23:05:33 PDT
Subject: Clearing the screen etc.
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: common-lisp@SU-AI.ARPA
cc: cl-windows@SU-AI.ARPA
Symbolics has adopted "window" in place of "screen" in its
naming conventions. I think this is the right thing, and is
superior to both "screen" and "terminal" except possibly in cases
where the display operation really does refer to a screen
or a terminal.
Also, with respect to naming, let me plug my preference; rather
than add a lot of DO-THIS-OR-THAT functions, I'd rather add ONE
function, which encapsulates all screen operations. I have in mind
the general form;
(displayop <<displaystream>> <<operation>> &rest args)
This general form permits all "window" operations to be
recognized trivially, permits generic and implementation specific
extensions, and permits both "flavorized" and "macroized"
implementations. It also has the advantage of not polluting
the language with a lot more random function names.
The CL-WINDOWS mailing list (which I theoretically moderate)
is pretty moribund, mainly from the inability to sustain a
conversation. I have a feeling that each of the CL
implementations is pretty set in its own way of handling
displays, and the efficiency issues, combined with the
extremely low-level nature of display drivers, make any
compromise agreement on "standards" for fully elaborated
displays unlikely. As such, I support the idea of
chipping off this piece of the problem.
-------
∂30-Jul-85 0915 STENGER%ti-csl.csnet@csnet-relay.arpa Re: Clearing the screen etc.
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 09:15:07 PDT
Received: from ti-csl by csnet-relay.csnet id aa16380; 30 Jul 85 12:07 EDT
Date: 30 Jul 1985 0938-CDT
From: Dan Stenger <STENGER%CSL60%ti-csl.csnet@csnet-relay.arpa>
Subject: Re: Clearing the screen etc.
To: cl-windows@su-ai.ARPA
In-Reply-To: Your message of 29-Jul-85 2305-CDT
Received: from csl60 by ti-csl; Tue, 30 Jul 85 10:01 CST
Date: 29 Jul 1985 23:05:33 PDT
Subject: Clearing the screen etc.
From: Dave Dyer <DDYER@USC-ISIB>
To: common-lisp@SU-AI
cc: cl-windows@SU-AI
Symbolics has adopted "window" in place of "screen" in its
naming conventions. I think this is the right thing, and is
superior to both "screen" and "terminal" except possibly in cases
where the display operation really does refer to a screen
or a terminal.
I agree with this. I think the term "window" is well accepted in the
lisp community and we should not try to change the consensus.
Also, with respect to naming, let me plug my preference; rather
than add a lot of DO-THIS-OR-THAT functions, I'd rather add ONE
function, which encapsulates all screen operations. I have in mind
the general form;
(displayop <<displaystream>> <<operation>> &rest args)
This general form permits all "window" operations to be
recognized trivially, permits generic and implementation specific
extensions, and permits both "flavorized" and "macroized"
implementations. It also has the advantage of not polluting
the language with a lot more random function names.
I don't think I agree with this totally. I think that windows should
be compatible with streams (maybe even a subtype of stream) and this
naming scheme doesn't fit with the currently defined stream functions.
(I would like to hear how others feel about windows as streams.)
Also I feel that we should maintain the current naming conventions
such as MAKE-WINDOW for creating a new window. If structures are used
for implementation of windows the automatically generated functions
would all need renaming in some way. However I do agree with your
goal of limiting the addition of a bunch of new function names.
The CL-WINDOWS mailing list (which I theoretically moderate)
is pretty moribund, mainly from the inability to sustain a
conversation. I have a feeling that each of the CL
implementations is pretty set in its own way of handling
displays, and the efficiency issues, combined with the
extremely low-level nature of display drivers, make any
compromise agreement on "standards" for fully elaborated
displays unlikely. As such, I support the idea of
chipping off this piece of the problem.
I guess I'm not quite as pessimistic. Agreeing on a standard for the
Lisp language was probably an even tougher job. Also after the
agreement was reached companies with existing Lisp implementations
(such as Symbolics) went to a lot of trouble and probably even
sacrificed some performance to support the standard. I know that TI
would be willing to support a reasonable Common Lisp window standard.
Dan Stenger
-------
∂17-Dec-85 2157 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 21:38:11 PST
Received: from tektronix by csnet-relay.csnet id ag21296; 17 Dec 85 21:43 EST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: cl-windows@su-ai.ARPA, cl-graphics@su-ai.ARPA
Received: from tekchips by tektronix with smtp ; 17 Dec 85 15:26:20 PST
Date: Tuesday, 17 Dec 85 15:16:03 PST
PL add me to your mailing list.
sridhar%tekchips@tektronix.csnet
∂16-Dec-86 1905 RICHER@SUMEX-AIM.STANFORD.EDU CL-WINDOWS mailing list
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 86 18:57:41 PST
Date: Tue 16 Dec 86 18:54:34-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: CL-WINDOWS mailing list
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12263390243.65.RICHER@SUMEX-AIM.STANFORD.EDU>
You are receiving this message because you are on one of two
distribution lists, soon to be merged. The first list is
CL-WINDOWS@SU-AI.ARPA which began in Fall 1984. I think this list was
started to discuss a Commonlisp Window Standard. Ignorant of this
list, but interested in a Commonlisp Window Standard, and more recently,
Commonlisp implementations (on lisp machines) or interfaces (on Unix
workstations) of/to X and NeWS (servers), with application programmer
libraries done in an object-oriented language (eventually something that is
compatible with the sometime-to-come CL object standard, supposedly
some variant of Commonloops), I set out to find other interested
individuals. There seems to be enough interest in these topics to
warrant a discussion list, but it seems appropriate to merge with the
existing CL-WINDOWS list. Because Dick Gabriel, the maintainer of the
CL-WINDOWS list agreed to this arrangement and in particular, felt
that discussion of lisp window systems related to the X, NeWS, and
Commonloops "standards" was appropriate on CL-WINDOWS, I am forwarding
the list of addresses I have recently collected to Dick and he will
add them to his list. Note that there have been no messages on the
list that I was thinking of starting. However, there have been messages on
CL-WINDOWS dating back to two years ago. (Below is a description of
CL-WINDOWS when it started.) I FTPED the archives from SAIL (=SU-AI)
and there are quite a few messages from the past. However, the last
message I found was Dec. 1985? I don't know if that is really the
last message or not? Anyhow, please contribute something stimulating and
intelligent wrt to these issues. If you do not want to be on this
list, (so sorry), and if you think I'm the culprit, then send me a
message and I'll forward to Dick. By the way there are other related
lists of possible interest:
xpert@athena.mit.edu
xport@athena.mit.edu
news-makers@brillig.umd.edu
cl-graphics@su-ai.arpa
common-lisp@su-ai.arpa
commonloops.pa@xerox.com
In each case, add -request and mail a request to get on (e.g.,
xpert-request@athena.mit.edu)
I do not maintain or moderate any of these lists.
Dick will maintain the CL-WINDOWS mailing list, but messages are not
filtered or digested at this point in time.
By the way I would suggest that places like Xerox and Symbolics which
have multiple addresses even on my list, set up a local redistribution
list. If someone can do that, forward the information to
cl-windows-request@su-ai.arpa.
-----------------------------------------------------------------------------
First message in Cl-WINDOWS, Fall 1984
Introduction
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:
CL-Windows@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLWIND.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Windows-request@su-ai.arpa
-------
∂16-Dec-86 2254 RICHER@SUMEX-AIM.STANFORD.EDU purpose of mailing list
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 86 22:54:05 PST
Date: Tue 16 Dec 86 19:55:48-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: purpose of mailing list
To: "CLW:": ;
cc: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12263401391.16.RICHER@SUMEX-AIM.STANFORD.EDU>
I'm sorry if I haven't clarifed things well, and in case I didn't
I better make sure now before we merge the lists. My feeling was
that a lot of people interested in some combination of X/NEWS, Commonlisp,
COmmonloops are interested in sharing information, and maybe even
code with regard to what they are doing with these things. This is
different than the initial focus of CL-WINDOWS which was trying to iron
out a standard. I'm happy to see the info kind of list I envisioned
merged with the CL-WINDOWS "standards discussion" list, but I think we
need to make sure that's really a good idea in most people's minds.
Because the CL-WINDOWS messages seemed to have come to halt unless I
am mistaken, it sounds like some discussion about what people are
actually doing isn't a bad idea. But that means some detailed messages
perhaps about implementation related stuff being mixed with high-level
discussion about standards. If you think this marriage is a bad idea,
speak up now ... you should probably reply ONLY to me in most cases
since a lot of people might not care one way or the other.
Mark
-------
∂17-Dec-86 0556 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU X server implementors?
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86 05:56:20 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Dec 86 08:52-EST
Date: Wed, 17 Dec 86 08:50 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X server implementors?
To: xport@ATHENA.MIT.EDU, xpert@ATHENA.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
Message-ID: <861217085012.9.RWS@KILLINGTON.LCS.MIT.EDU>
If there is anyone out there contemplating implementing an X V11 server
in a language other than C, or as multiple processes, and is willing
to admit it (at least privately to me), I would like to talk with you.
∂17-Dec-86 2251 RICHER@SUMEX-AIM.STANFORD.EDU a bunch of messages on X/News & Commonlisp
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86 22:51:23 PST
Date: Wed 17 Dec 86 17:54:24-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: a bunch of messages on X/News & Commonlisp
To: "CLW:": ;
cc: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12263641434.77.RICHER@SUMEX-AIM.STANFORD.EDU>
The messages below were received as responses to one of two enquires:
(1) information on people using X, PCL, HP-CL, and GNU emacs on HP bobcats,
(2) query to people on xpert, common-lisp, and commonloops mailing list
about their interest and activites regarding Commonlisp/Commonloops
window systems interfaced to X (or NeWS).
I have only included responses that might be of general interest; mostly
explaining what people are doing. You might be interested to know that
the responses I have received including the just "add-me-to-the list" ones
not printed below include people using all sorts of hardware at all sorts
of places.
15-Nov-86 07:01:52-PST,1200;000000000001
Return-Path: <carter%silicon@utah-cs.arpa>
Received: from utah-cs.ARPA by SUMEX-AIM.ARPA with TCP; Sat 15 Nov 86 07:01:50-PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA03585; Sat, 15 Nov 86 08:03:18 MST
Received: by silicon.ARPA (4.30/4.40.2)
id AA01102; Sat, 15 Nov 86 08:10:36 mst
Date: Sat, 15 Nov 86 08:10:36 mst
From: carter%silicon@utah-cs.arpa (Tony M. Carter)
Message-Id: <8611151510.AA01102@silicon.ARPA>
To: richer@sumex-aim.arpa
Subject: X and CommonLisp
Cc: hucka@utah-cs.arpa, kessler%orion@utah-cs.arpa
We currently use hp-cl running as a subshell under gnu and are having good
success --- it is MUCH less painful than using NMODE. We are also in the
process of interfacing to the X library so that cl can handle windows, etc.
Some students are undertaking a project to construct a user-interface package
with mouse-sensitive objects. Unfortunately, we don't have CommonLoops yet,
so we are implementing on top of a local package we call frobs (frame objects)
which will permit us to do intelligent reasoning about objects as well. We
believe that frobs can be brought up on top of CommonLoops when it becomes
available.
Tony Carter (carter@utah-cs)
15-Nov-86 13:22:13-PST,1203;000000000001
Return-Path: <kessler%utah-orion@utah-cs.arpa>
Received: from utah-cs.ARPA by SUMEX-AIM.ARPA with TCP; Sat 15 Nov 86 13:22:11-PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA12899; Sat, 15 Nov 86 14:23:44 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA26810; Sat, 15 Nov 86 14:23:41 MST
Date: Sat, 15 Nov 86 14:23:41 MST
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8611152123.AA26810@utah-orion.ARPA>
To: RICHER@sumex-aim.arpa
Subject: X, GNU, and HPCL
That is exactly the configuration that we are running on most of our systems.
We usually run GNU with HPCL in GNU window and other windows with shells and
RLOGIN's to various machines. It works quite well. We also have a project
developing an combined objects and frame system called (FROBS). A group is
interfacing X window operations to FROBS.
Anyway, we have a new shell.el that makes gnu run the HPCL with gnu better.
Also, we have made a number of hacks to X to fix them (you might have seen
the messages). If you want further information, contact thomas@utah-gr.arpa
for X information, stoller@utah-orion.arpa for GNU information and maybe
mjb@utah-orion.arpa for HPCL help.
Bob.
16-Nov-86 10:51:14-PST,957;000000000001
Return-Path: <hearn%hilbert@rand-unix.ARPA>
Received: from rand-unix.ARPA by SUMEX-AIM.ARPA with TCP; Sun 16 Nov 86 10:51:09-PST
Received: from hilbert.arpa (hilbert) by rand-unix.ARPA; Sun, 16 Nov 86 09:33:17 pst
Received: by hilbert.arpa; Sun, 16 Nov 86 09:26:50 pst
From: Tony Hearn <hearn%hilbert@rand-unix.ARPA>
Message-Id: <8611161726.AA00250@hilbert.arpa>
To: Mark Richer <RICHER@sumex-aim.arpa>
Cc: hpai%hilbert@rand-unix.ARPA
Subject: Re: X and Commonlisp
In-Reply-To: Your message of Fri 14 Nov 86 14:05:56-PST.
<12254949090.12.RICHER@SUMEX-AIM.ARPA>
Date: Sun, 16 Nov 86 09:26:47 PST
We'd certainly like to share such information with you. As a matter of fact,
we are using PSL for most of our research rather than Common LISP, but the
X - GNU - lisp model remains the same.
If you make up a mailing list, add "hpai%hilbert@rand-unix.arpa" to it.
That reaches all interested parties here.
Thanks,
Tony Hearn
20-Nov-86 14:19:42-PST,925;000000000001
Return-Path: <sundar@hermes.ai.mit.edu>
Received: from hermes.ai.mit.edu by SUMEX-AIM.ARPA with TCP; Thu 20 Nov 86 14:19:29-PST
Received: by hermes.ai.mit.edu; Thu, 20 Nov 86 17:19:38 EST
Date: Thu, 20 Nov 86 17:19:38 EST
From: sundar@hermes.ai.mit.edu (Sundar Narasimhan)
Message-Id: <8611202219.AA05039@hermes.ai.mit.edu>
To: RICHER@sumex-aim.arpa
In-Reply-To: Mark Richer's message of Thu 20 Nov 86 11:57:55-PST
Subject: X and lisp graphics
Hi:
I would be grateful if you could forward to me any replies you get in
response to your query of integrating X and Lisp graphics. I started
on something like this some time ago, but have had to shelve it for a
while owing to other time constraints. What I have working is an
interface between X and Lucid lisp using Lucid's foreign call
interface but with a layer of flavors inbetween. I plan to finish it
sometime when I get the time to do it.
-Sundar.
20-Nov-86 15:24:28-PST,783;000000000001
Return-Path: <chris@columbia.edu>
Received: from columbia.edu by SUMEX-AIM.ARPA with TCP; Thu 20 Nov 86 15:24:23-PST
Received: by columbia.edu (5.54/1.14)
id AA02942; Thu, 20 Nov 86 18:25:19 EST
Date: Thu, 20 Nov 86 18:25:19 EST
From: Chris Maio <chris@columbia.edu>
Message-Id: <8611202325.AA02942@columbia.edu>
To: richer@sumex-aim.arpa
In-Reply-To: Mark Richer's message of Thu 20 Nov 86 11:57:55-PST
Subject: X and lisp graphics
Mark,
I'm glad to hear about the Utah effort to add X compatibility to the HP
Common Lisp, since I'm interested in doing the same thing for NeWS on the
Bobcat. I have no idea at this point whether we'll get beta-test status for
NeWS or how much help HP will provide us, but I'll let you know if I get
anywhere.
Chris
21-Nov-86 11:48:04-PST,1640;000000000001
Return-Path: <tsf@theory.cs.cmu.edu>
Received: from THEORY.CS.CMU.EDU by SUMEX-AIM.ARPA with TCP; Fri 21 Nov 86 11:47:57-PST
Date: Friday, 21 November 1986 14:48:01 EST
From: Timothy.Freeman@theory.cs.cmu.edu
To: Mark Richer <RICHER@sumex-aim.arpa>
Subject: Re: X and lisp graphics
Message-ID: <1986.11.21.18.58.41.Timothy.Freeman@theory.cs.cmu.edu>
In-Reply-To: <12256498649.76.RICHER@SUMEX-AIM.ARPA>
We have some code that uses X from Lucid (er, Sun) Lisp. However, it
only does characters, lines, and rectangles. It was written to be
downward compatible with another equally anemic, poorly-written piece
of code that ran on another machine. I can send it to you if you
want, but you should definitely use it as an example of working code
instead of as a foundation for code that you actually intend to use
for a long time.
I discovered documentation for X in the subdirectory doc of the X
distribution. It describes what routines to call from C to pop up
windows, draw lines, characters, and so forth. To get things other
than boring text from xterm, you have to deal with X directly. I will
mail you the documentation too, if you want, but you are probably
better off getting it directly from MIT.
If you do get a nice piece of code up and running, I would certainly
be interested in seeing it.
There has been some work on defining a standard graphics interface for
common lisp. You may want to post to the common lisp mailing list
asking for information about that sort of thing so you don't wind up
reinventing the wheel in such a way that your wheels are incompatible
with everyone else's.
9-Dec-86 17:25:48-PST,556;000000000001
Return-Path: <klee@ads.ARPA>
Received: from grape.ads.ARPA (ADS.ARPA.#Internet) by SUMEX-AIM.ARPA with TCP; Tue 9 Dec 86 17:25:45-PST
Date: Tue, 9 Dec 86 17:24:30 pst
From: klee@ads.ARPA (Ken Lee)
To: richer@sumex-aim.arpa
Subject: Re: X window system
Mark,
I am interested in CommonLisp interfaces to SunNEWS. Please add me
to your mailing lisp. I am doing applied research in the area of
object-oriented (flavors) interactive graphics tools for user interfaces
to LISP AI systems.
Ken Lee
Advanced Decision Systems
Mountain View, CA
9-Dec-86 19:31:38-PST,1627;000000000001
Return-Path: <FAHLMAN@C.CS.CMU.EDU>
Received: from C.CS.CMU.EDU by SUMEX-AIM.ARPA with TCP; Tue 9 Dec 86 19:31:30-PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 9 Dec 86 22:33:45-EST
Date: Tue, 9 Dec 1986 22:33 EST
Message-ID: <FAHLMAN.12261562345.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Cc: slisp@C.CS.CMU.EDU
Subject: X window system
In-reply-to: Msg of 9 Dec 1986 19:03-EST from Mark Richer <RICHER at SUMEX-AIM.ARPA>
Mark,
It looks like the standard workstation configuration around CMU is going
to be the Mach operating system, X, and Common Lisp -- our own Common
Lisp on the IBM RT's, and Lucid's Common Lisp on the microVaxen and
Suns. We will be developing a Common Lisp to X interface for our own
use, and would like to participate in any discussions leading toward the
standardization of this interface.
The whole Spice Lisp group here will be involved in this in one way or
another, so for now it is probably best just to add "slisp@c.cs.cmu.edu"
to your mailing list. If this becomes unwieldy, we'll change the
arrangements later.
We're probably not as far along in our knowledge of X as other groups --
we only received a version of X for the IBM RT this week, and don't yet
have it running under Mach. We do have some experience in building
hairy Common Lisp interfaces to other things, however.
Thanks for taking the initiative in setting this up. The sooner people
start talking, the less has to be undone in order to make everyone's
system compatible.
-- Scott
9-Dec-86 21:57:03-PST,726;000000000001
Return-Path: <ehl%cogsci.Berkeley.EDU@BERKELEY.EDU>
Received: from cogsci.berkeley.edu ([128.32.130.5].#Internet) by SUMEX-AIM.ARPA with TCP; Tue 9 Dec 86 21:56:50-PST
Received: by cogsci.berkeley.edu (5.57/1.17)
id AA22770; Tue, 9 Dec 86 21:57:39 PST
Date: Tue, 9 Dec 86 21:57:39 PST
From: ehl%cogsci.Berkeley.EDU@berkeley.edu (Edward H. Lay)
Message-Id: <8612100557.AA22770@cogsci.berkeley.edu>
To: richer@sumex-aim.stanford.edu
Subject: X & PCL
I am interested in being on your mailing list about X and PCL etc.
I am currently involved in porting the Boxer System to a Sun running
Common Lisp, PCL and possible X (we are still evaluating different
window systems.)
edward lay (ehl@cogsci.berkeley.edu)
10-Dec-86 08:24:27-PST,845;000000000001
Return-Path: <cagan%hplmrc@hplabs.HP.COM>
Received: from hplabs.HP.COM by SUMEX-AIM.ARPA with TCP; Wed 10 Dec 86 08:24:11-PST
Received: from hplms1 by hplabs.HP.COM ; Wed, 10 Dec 86 07:44:08 pst
Received: from hplmrc (hplmrc) by hplms1; Wed, 10 Dec 86 07:43:50 pst
Return-Path: <cagan@hplmrc>
Received: from hplmrc by hplmrc ; Wed, 10 Dec 86 07:43:20 pst
Message-Id: <8612101543.AA08480@hplmrc>
To: richer@sumex-aim.ARPA
X-Mailer: mh
Subject: CommonLisp/X Mailing List
Date: Wed, 10 Dec 86 07:42:06 PST
From: Marty Cagan <cagan%hplmrc@hplabs.HP.COM>
Mark,
We've implemented both a CL interface to Xlib, and a Common Objects
interface to the Xray lib. We've also been experimenting with
a CommonLoops (Classes) interface to Xlib. Can you put me on the
new mailing list please?
Thanks,
Marty Cagan (cagan@hplabs)
10-Dec-86 08:50:54-PST,677;000000000003
Return-Path: <rfb@h.cs.cmu.edu>
Received: from H.CS.CMU.EDU by SUMEX-AIM.ARPA with TCP; Wed 10 Dec 86 08:50:50-PST
Date: 10 Dec 1986 11:08-EST
From: Rick.Busdiecker@h.cs.cmu.edu
To: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: Re: Windows in COmmonloops?
Message-Id: <534614920/rfb@h.cs.cmu.edu>
In-Reply-To: Mark Richer's mail message of Tue, 9 Dec 86 16:08:12 PST
I'm developing a customizable graphics editor in CommonLoops. Once the
SpiceLisp (now CMU CommonLisp) hooks to X are made (real soon) I will
be including X as one of the window managers that I support. It should
become the primary window manager for my development work before long.
Rick
10-Dec-86 21:12:03-PST,766;000000000001
Return-Path: <Rao.pa@Xerox.COM>
Received: from Xerox.COM by SUMEX-AIM.ARPA with TCP; Wed 10 Dec 86 21:11:55-PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 DEC 86 19:16:01 PST
Date: 10 Dec 86 19:15 PST
Sender: Rao.pa@Xerox.COM
To: RICHER@SUMEX-AIM.ARPA
From: RAO.pa@Xerox.COM
Subject: Re: Windows in COmmonloops?
Message-ID: <861210-191601-5020@Xerox>
Message type: Message
Topic:
Text:
Re: Message of Tue, 9 Dec 86 16:08:12 PST from Mark Richer
<RICHER@SUMEX-AIM.ARPA>
I'm doing my masters thesis at MIT on building a window system in
CommonLoops for Xerox Commonlisp. One of my goals is to be able to
build X easily on top of this window system.
Please add me to your distribution list.
ramana
rao.pa@xerox.com
15-Dec-86 12:15:18-PST,1299;000000000001
Return-Path: <cerys@XX.LCS.MIT.EDU>
Received: from XX.LCS.MIT.EDU by SUMEX-AIM.ARPA with TCP; Mon 15 Dec 86 12:14:32-PST
Received: from RTS-12.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Dec 86 15:18-EST
REPLY-TO: cerys@XX
FCC: vx:/usr/cerys/outgoing-mail
FROM: Dan Cerys <cerys@XX>
TO: Mark Richer <RICHER@SUMEX-AIM.ARPA>
SUBJECT: Re: X window system
DATE: 15-Dec-86 15:15:58
SENDER: cerys@XX
MESSAGE-ID: <cerys.2744050557@RTS-12>
Please add me to this list. Bob Scheifler has already done a V10 X
windows implementation for LISPM's. I've been talking to him about an
implementation for V11 of X windows on Explorers and Symbolics.
Dan
16-Dec-86 11:42:44-PST,811;000000000001
Return-Path: <lowry%bizet.DEC@decwrl.DEC.COM>
Received: from decwrl.dec.com by SUMEX-AIM.STANFORD.EDU with TCP; Tue 16 Dec 86 11:42:34-PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA20897; Tue, 16 Dec 86 11:45:26 PST
Message-Id: <8612161945.AA20897@decwrl.dec.com>
Date: Tuesday, 16 Dec 1986 11:39:20-PST
From: lowry%bizet.DEC@decwrl.DEC.COM (DAVID LOWRY 225-6290 BIZET::LOWRY)
To: richer@sumex-aim.ARPA
Subject: X window system
Hi, I'm writing the X window routines that will be included in
the next release of Vax Lisp. I would like to be put on your mailing
list for the common lisp X window distribution.
Who am I?
David Lowry
lowry%bach.dec@decwrl.dec.com
Digital Equipment Corporation
77 Reed Road HL02-3/C10
Hudson, MA 01749
Many Thanks.
DDL
17-Dec-86 06:07:47-PST,829;000000000001
Return-Path: <@SAIL.STANFORD.EDU:RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU>
Received: from SAIL.STANFORD.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Wed 17 Dec 86 06:07:46-PST
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86 05:56:20 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Dec 86 08:52-EST
Date: Wed, 17 Dec 86 08:50 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X server implementors?
To: xport@ATHENA.MIT.EDU, xpert@ATHENA.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
Message-ID: <861217085012.9.RWS@KILLINGTON.LCS.MIT.EDU>
If there is anyone out there contemplating implementing an X V11 server
in a language other than C, or as multiple processes, and is willing
to admit it (at least privately to me), I would like to talk with you.
-------
∂26-Dec-86 1428 RICHER@SUMEX-AIM.STANFORD.EDU [Ralph R. Swick <swick@ATHENA.MIT.EDU>: User Interface Toolkit proposal]
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86 14:27:53 PST
Date: Fri 26 Dec 86 14:27:42-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: [Ralph R. Swick <swick@ATHENA.MIT.EDU>: User Interface Toolkit proposal]
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12265963100.15.RICHER@SUMEX-AIM.STANFORD.EDU>
If you are on the xpert mailing list you have seen the message forwarded
below. I am forwarding to cl-windows because I believe any proposed
user interface toolkit for X might be of interest to readers here
(that are not on xpert) and particularly because it can impact lisp
window systems to the degree that they support or are interfaced to X.
---------------
Return-Path: <swick@ATHENA.MIT.EDU>
Received: from ATHENA by SUMEX-AIM.STANFORD.EDU with TCP; Wed 24 Dec 86 09:29:56-PST
Received: by ATHENA (5.45/4.7)
id AA27342; Wed, 24 Dec 86 11:55:44 EST
Received: by LYRE (5.45/4.7)
id AA16343; Wed, 24 Dec 86 11:55:14 EST
Message-Id: <8612241655.AA16343@LYRE>
To: xpert
Subject: User Interface Toolkit proposal
Date: Wed, 24 Dec 86 11:55:02 -0500
From: Ralph R. Swick <swick@ATHENA.MIT.EDU>
A draft proposal for a user interface toolkit is available for ftp in
the pub directory on zap.mit.edu [18.72.0.126].
This document has resulted from an intensive effort on the part of
Digital Equipment Corporation and Hewlett-Packard Company to merge the
better features of the toolkits in the X.V10R4 distribution and
extract a common foundation upon which a variety of application
environments may be built. Their stated goal is to provide the next
higher level of common (portable) interfaces above Xlib.
M.I.T. has a goal to have available at least a preliminary version of
a user interface toolkit and one or more application environments (UIMS)
to be distributed with the first general distribution of X version 11.
The document "X Toolkit, A Proposed Architecture" is distributed for your
comment and to let you know one of the directions in which we are headed.
If we are to achieve the availability date as stated, the period during
which comments can be expected to have major impact on the implementation
is unfortunately very short. We do, however, invite those comments.
The list of individual contributors to this draft is already very long;
a future revision of a specification will give them the recognition
they deserve.
I hope that applications developers who need to use one of the
applications environments distributed with X version 10 release 4 will be
able to use this draft proposal to prioritize and partition their
development effort.
Ralph R. Swick
M.I.T. Project Athena
Swick@Athena.MIT.EDU
-------
∂26-Dec-86 1437 RICHER@SUMEX-AIM.STANFORD.EDU [kddlab!elis03@vc.sra.junet (Ken Seo): x-window in lisp]
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86 14:37:14 PST
Date: Fri 26 Dec 86 14:37:00-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: [kddlab!elis03@vc.sra.junet (Ken Seo): x-window in lisp]
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12265964795.15.RICHER@SUMEX-AIM.STANFORD.EDU>
Those of you on xpert will probably vote to have me shot but here is
another forwarded message (I think the xpert msgs. of interest to cl-windows
will be very small in number so bear with this please):
---------------
Return-Path: <kddlab!titcca!vc!elis03@titcca.cc.titech.junet>
Received: from ATHENA by SUMEX-AIM.STANFORD.EDU with TCP; Fri 26 Dec 86 00:18:34-PST
Received: by ATHENA (5.45/4.7)
id AA06733; Fri, 26 Dec 86 02:33:11 EST
Received: from kddlab.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA14489; Fri, 26 Dec 86 02:31:42 EST
Received: by kddlabs.junet ; Thu, 25 Dec 86 21:40:15+0900
Received: by kddlabs.junet ; Thu, 25 Dec 86 21:40:07+0900
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
id AA23323; Thu, 25 Dec 86 09:27:22 jst
Received: from vc.sra.junet by srava.sra.junet (4.13/6.2Junet)
id AA16646; Thu, 25 Dec 86 09:08:56 jst
Received: by vc.sra.junet (4.13/6.1Junet)
id AA05683; Thu, 25 Dec 86 09:07:39 jst
Date: Thu, 25 Dec 86 09:07:39 jst
From: kddlab!elis03@vc.sra.junet (Ken Seo)
Return-Path: <elis03@vc.sra.junet>
Message-Id: <8612250007.AA05683@vc.sra.junet>
To: kddlabs!xpert%athena.mit.edu@seismo.CSS.GOV
Subject: x-window in lisp
Dec. 25,1986
To whom it may concern,
In August of 1986, Jim Gettys posted the proposed revisions for
version 11 of X window on the net. I got it through the University
of Tokyo relay (here in Japan).
In the prologue, he added the fact that a lisp version of
X window would be finished in March of 1987.
I would like to know the present status of the lisp version of
X window. Also, which lisp dialog it is being written in.
Please send your answers to the following address;
elis03@sravc.sra.junet (via the u-tokyo.junet relay)
Thank you very much.
Yours truly,
Harlan Seo
address:
c/o SRA
Hirakawacho 1-1-1
Chiyoda-ku, Tokyo
Japan 105
Tel: (03)234-2623
e-mail: elis03@sravc.sra.junet
-------
∂26-Dec-86 1753 gabriel@vaxa.isi.edu cl-windows mailing list
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86 17:53:13 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA05858; Fri, 26 Dec 86 17:39:34 pst
From: gabriel@vaxa.isi.edu (Gabriel Robins)
Message-Id: <8612270139.AA05858@vaxa.isi.edu>
Date: 26 Dec 1986 1739-PST (Friday)
To: cl-windows@sail.stanford.edu
Subject: cl-windows mailing list
Please add me to the list. Thanks,
Gabe
∂27-Dec-86 0958 ho@ucbarpa.Berkeley.EDU CL-windows
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 86 09:58:24 PST
Received: by ucbarpa.Berkeley.EDU (5.57/1.18)
id AA06079; Sat, 27 Dec 86 09:58:46 PST
Date: Sat, 27 Dec 86 09:58:46 PST
From: ho@ucbarpa.Berkeley.EDU (Kinson Ho)
Message-Id: <8612271758.AA06079@ucbarpa.Berkeley.EDU>
To: cl-windows@sail.stanford.edu
Subject: CL-windows
Please put me on the cl-windows mailing list. Thank you.
Kinson Ho (ho@ucbarpa.Berkeley.edu)
∂27-Dec-86 1556 wanginst!ulowell!ulowell.ULOWELL.EDU!grinstei@harvard.HARVARD.EDU please add me to the list
Received: from HARVARD.HARVARD.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 86 15:56:37 PST
Received: by harvard.HARVARD.EDU; Sat, 27 Dec 86 18:56:52 EST
Received: by wanginst.EDU (4.12/5.8.WangInst)
id AA03867; Sat, 27 Dec 86 17:54:44 est
Posted-Date: Sat, 27 Dec 86 15:21:00 EST
Received: by ulowell.ULOWELL.EDU (5.51/UUCP-Project/rel-1.0/12-23-86)
id AA18548; Sat, 27 Dec 86 15:21:00 EST
Date: Sat, 27 Dec 86 15:21:00 EST
From: wanginst!grinstei@ulowell.ULOWELL.EDU (Georges Grinstein)
Message-Id: <8612272021.AA18548@ulowell.ULOWELL.EDU>
To: cl-windows@sail.stanford.edu
Subject: please add me to the list
Cc: grinstein@harvard.HARVARD.EDU
UUCP: wanginst!ulowell!grinstein Dr. Georges Grinstein
ARPA: grinstein@ulowell.CSNET University of Lowell
VOX: +1 617 452 5000 x2681 Lowell MA 01854 USA
∂28-Dec-86 0917 UEJIOWH%CADVAX.decnet@ge-crd.arpa cl-window mailing list
Received: from GE-CRD.ARPA by SAIL.STANFORD.EDU with TCP; 28 Dec 86 09:17:00 PST
Date: 28 Dec 86 12:16 EST
From: UEJIOWH%CADVAX.decnet@ge-crd.arpa
Subject: cl-window mailing list
To: CL-WINDOWS@SAIL.STANFORD.EDU
Please add me to the cl-window mailing list
thanks,
wayne uejio
ge cr&d
bldg 37/rm 523
one river road
schenectady, ny 12345
518-387-6770
∂29-Dec-86 0634 PB80@A.CS.CMU.EDU Add to mailing list please
Received: from A.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86 06:33:57 PST
Date: Mon, 29 Dec 86 09:38 EST
From: Paul.Birkel@A.CS.CMU.EDU
To: cl-windows@SU-AI.ARPA
Subject: Add to mailing list please
Message-Id: <29Dec86.093851.PB80@A.CS.CMU.EDU>
Please add my name/address to the cl-windows mailing list.
Thank you.
Paul Birkel
pab@K.CS.CMU.EDU
∂29-Dec-86 0839 spe@cad.cs.cmu.edu Please add me
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86 08:39:15 PST
Date: 29 Dec 1986 11:37-EST
From: Sean.Engelson@cad.cs.cmu.edu
To: cl-windows@sail.stanford.edu
Subject: Please add me
Message-Id: <536258226/spe@cad.cs.cmu.edu>
Please add me to the Common Lisp Windows mailing group.
Thanks,
-Sean-
spe@cad.cs.cmu.edu
∂29-Dec-86 0946 @KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU X in lisp
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86 09:41:46 PST
Received: by ATHENA (5.45/4.7)
id AA09426; Mon, 29 Dec 86 10:39:54 EST
Date: Mon, 29 Dec 86 10:40 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X in lisp
To: elis03@sravc.sra.junet, xpert@ATHENA.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8612250007.AA05683@vc.sra.junet>
Message-Id: <861229104019.5.RWS@KILLINGTON.LCS.MIT.EDU>
I am the guilty party claiming to do a lisp implementation of X.
I cannot guarantee when it will be done. My current expectation
is to have V11 server implementations for both 3600s and Explorers.
I have informal agreements with people at both Symbolics and TI
for them to provide some of the necessary code. The implementation
will be in CL, but using extended facilities (e.g., LOOP). The
level of dependence on Flavors has not yet been determined.
The expected form of the implementation is a multi-process server
(one process per client connection, plus a few others). The
"screen" will be a vanilla window in the native window system;
that is, this will be a window system within a window system,
a "virtual console" approach.
I also hope to have a V11 client end implemented on both systems,
but in a quite different form than most other people seem to
be hacking. The idea is to implement a flavor obeying the
screen protocol of the native window system. In this way,
applications written to the native window system can run
transparently across the net. I already have a V10 implementation
of this mostly running on 3600s. This also follows the
virtual console model; what pops up on the remote screen is
a single X window, inside of which is a complete lispm window
system.
∂29-Dec-86 1129 RICHER@SUMEX-AIM.STANFORD.EDU Re: CL-WINDOWS mailing list
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86 11:29:08 PST
Date: Mon 29 Dec 86 11:28:50-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: CL-WINDOWS mailing list
To: commonloops.pa@XEROX.COM, common-lisp@SAIL.STANFORD.EDU,
xpert@ATHENA.MIT.EDU, news-makers@BRILLIG.UMD.EDU,
RICHER@SUMEX-AIM.STANFORD.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12265972863.15.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <12266716971.39.RICHER@SUMEX-AIM.STANFORD.EDU>
I apologize to people on cl-windows for saying that you get on the list
by mailing to CL-WINDOWS@SAIL.STANFORD.EDU .... I meant to type
CL-WINDOWS-REQUEST@..... As many of you know adding -REQUEST is a convention
for mailing adminstrative requests such as getting added to a list
(so everyone doesn't have to see those messages). Sorry. This proves I
am only human afterall,
Mark
-------
∂30-Dec-86 0719 pyramid!pyramid.UUCP!bein@hplabs.HP.COM mailing list request..
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 30 Dec 86 07:17:49 PST
Received: by hplabs.HP.COM ; Mon, 29 Dec 86 02:44:33 pst
Received: by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86)
id AA28898; Mon, 29 Dec 86 02:03:45 PST
Date: 29 Dec 1986 01:58-PST
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: mailing list request..
To: hplabs!cl-windows@sail.stanford.edu@hplabs.HP.COM
Message-Id: <536234323/bein@pyramid>
Please add me to the list.
Thanks in advance.
--David
∂30-Dec-86 1028 rw@cad.cs.cmu.edu mailing list
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Dec 86 10:25:40 PST
Date: 30 Dec 1986 13:25-EST
From: Rob.Woodbury@cad.cs.cmu.edu
To: cl-windows@sail.stanford.edu
Subject: mailing list
Message-Id: <536351112/rw@cad.cs.cmu.edu>
Please put me on the windows mailing list.
-rob woodbury-
∂30-Dec-86 1312 ekberg%home%ti-csl.csnet@RELAY.CS.NET CL-WINDOWS request
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Dec 86 13:12:44 PST
Received: from ti-csl by csnet-relay.csnet id ac00367; 30 Dec 86 16:06 EST
Received: from (home.ARPA) by tilde id AA05445; Tue, 30 Dec 86 13:10:45 cst
Received: by id AA05911; Tue, 30 Dec 86 13:11:10 cst
Date: Tue, 30 Dec 86 13:11:10 cst
From: Tom Ekberg <ekberg%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8612301911.AA05911@>
To: cl-windows@SU-AI.ARPA
Subject: CL-WINDOWS request
Please add ekberg@ti-csl to the CL-WINDOWS mailing list.
-- tom (aisle C-7)
∂05-Jan-87 0153 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET CL-WINDOWS
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Jan 87 01:53:24 PST
Received: from utokyo-relay by csnet-relay.csnet id ab00650; 5 Jan 87 4:44 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA01237; Mon, 5 Jan 87 17:19:23+0900
Received: by nttlab.ntt.junet (4.12/5.0N) with TCP; Mon, 5 Jan 87 15:26:23 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
id AA02230; Mon, 5 Jan 87 13:31:10 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.2Junet)
id AA00482; Mon, 5 Jan 87 13:21:25+0900
Date: Mon, 5 Jan 87 13:21:25+0900
From: Taiichi Yuasa <yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <yuasa@kurims.kurims.kyoto-u.junet>
Message-Id: <8701050421.AA00482@kurims.kurims.kyoto-u.junet>
To: cl-windows%sail.stanford.edu%u-tokyo.junet@RELAY.CS.NET
Subject: CL-WINDOWS
Please add my name on the CL-WINDOWS mailing list. Thanks.
Taiichi Yuasa
Research Institute for Mathemetical Sciences
Kyoto University, Kyoto 606, Japan
tel: Japan 075-751-2111 ext 7238 or 7209
∂05-Jan-87 0328 mcvax!inria!devin@seismo.CSS.GOV mailing list
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 5 Jan 87 03:27:34 PST
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA26645; Mon, 5 Jan 87 06:27:31 EST
Received: by mcvax.cwi.nl; Mon, 5 Jan 87 10:10:25 +0100 (MET)
Received: by inria.UUCP; Mon, 5 Jan 87 09:19:09 -0100 (MET)
Received: by inria.UUCP; Mon, 5 Jan 87 09:19:02 -0100 (MET)
Date: Mon, 5 Jan 87 09:19:02 -0100
From: mcvax!inria!devin@seismo.CSS.GOV (Matthieu Devin)
Message-Id: <8701050819.AA02962@inria.UUCP>
To: cl-windows@sail.stanford.edu
Subject: mailing list
Would you mind adding me to the cl-windows mailing list?
best regards
Matthieu Devin mcvax!inria!devin
∂06-Jan-87 1246 RICHER@SUMEX-AIM.STANFORD.EDU discussion items
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 12:45:57 PST
Date: Tue 6 Jan 87 12:46:26-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: discussion items
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12268828250.51.RICHER@SUMEX-AIM.STANFORD.EDU>
Because I am the instigator that is trying to get this list going
again, I feel I should make some effort to start some discussion. But
it really depends on everyone to keep things going. Please comment,
disagree, or raise completely different issues. I know many of you
have more to contribute than I do so please do.
I think there are at least two broad categories of messages
appropriate for the lisp: one is to discuss the standardization of
window systems in Commonlisp, the other to disseminate or obtain
information (I have a --- that does ---; Has anyone done ---? There
is a [paper, conference, workshop, etc.] that might be of interest.)
I have a few comments that are a "reaction" to what I read in the
cl-windows archives.Those messages are 1-2 years old so it's not
surprising that they are dated now.
(1) There was some discussion about whether to use objects for a
window standard. The issue was resolved then in favor of NO objects
because an object standard did not exist. Now there is lots of hope
that some variant of Commonloops will be accepted as a Commonlisp
standard this year. So the issue cannot be dismissed so easily now.
I'd like to hear your opinions on this. One thing to consider though
is whether or not a standard could satisfy both camps. Given that
Commonloops uses function-calling and lisp syntax would both camps be
satisfied if the standard included a set of operators and accessfns
that could be implemented with either standard functional programming
or with object-oriented programming?
Beyond a base level standard there is the need for toolkits.
Should they be done with objects? A lot of folks find that very
attractive.
(2) Earlier discussions on this list seemed to feel that a CL window
standard must support all kinds of terminals including CRTs or worse.
Personally, I think it would make things a lot simpler to concentrate
on bitmap displays and not worry about what would happen on CRTs. Only
in those cases where it really makes sense to add something t for
CRTs, etc. should this be a concern. Otherwise, I think that there
will be too much compromise, too much complexity, or time taken to
agree on anything.
I also feel that you should design different interfaces if you
expect the program to run on different kinds of displays. I don't
think that you will get the optimal interface for either a bitmap
display or a CRT if you write one piece of code for both. Therefore, I
don't see a big win in having all operations do something "reasonable"
on all displays even if possible.
;(3) There was some discussion as to whether there really should be a
separate group for a graphics standard. I think the emergence of
network-based window systems such as X and NeWS suggest that there is
a need to deal with both somewhat simulataneously. If you look at X
then you see the graphics stuff must be part of the protocol or there
must be a good way to add extensions (e.g., for 3-d graphics which are
not included in X at present). With NeWS you see that the graphics
primitives need be part of Postscript. So I think the coupling must be
tighter than some may have suggested.
(4) Finally, the emergence of X and NeWS adds a completely new
dimension to CL-WINDOWS discussions. Now we are in the position of
talking about adopting other standards and agreeing on a graceful
integration with CL that will serve people's needs for a long time.
IN the short run I don't think that any one standard (i.e., X or
NeWS) can be chosen as the one for the Commonlisp language. This
raises two sets of issues:
-Can we at least agree on standard Lisp/[X, NeWS] interfaces? Is there
a level above the low-level primitives that can be standardized so
that it doesn't matter to the application programmer whether X, NeWS,
or whatever is being used? And you can really run programs on
different systems?
-Is there a set of really low-level primitives that would allow one to
efficiently implement X, NeWS, or some future window system? And are
we ready to do this?
With regard to standarding Lisp/[X,NeWS] interfaces:
It seems that there are several routes to go. On UNIX workstations
people are using the X or NeWS server that is written in C and
communicating with the server process. However, in some cases people
are using foreign function call mechanisms (which I assume are
non-standard) to define lisp functions equivalent to some existing X
function written in C. Other people are using unix pipes. On lisp
machines people are taking the approach of writing the server in Lisp.
I think we have to allow for various implementation approaches.
However, I think we want to make sure that the application programmer
does NOT have to know which implementation approach has been taken,
and furthermore code is fully compatible across hardware systems.
Otherwise, what's the point of pretending you have a standard.
Regardless of what happens in the future I think there will be X
servers available (and usually supported) on lots of hardware
configurations. Anyhow that seems to be the trend now. If NeWS catches
on then a similar thing may happen. I feel confident I will soon find
Commonlisp and X on most hardware systems, but will my Lisp
window/graphics stuff work without modification (assuming display
capabilities are similar, i.e., Vanilla X let's say) concerns me.
Mark
-------
∂06-Jan-87 1437 RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU toolkits
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 14:37:08 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 6 Jan 87 17:39-EST
Date: Tue, 6 Jan 87 17:38 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: toolkits
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12268828250.51.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870106173842.4.RWS@KILLINGTON.LCS.MIT.EDU>
For what it's worth, a toolbox/toolkit proposal for X
(mostly for C) has recently been floated by DEC/HP/MIT.
Copy can be obtained via anonymous FTP to zap.mit.edu
(18.72.0.126) as /pub/proposal.out (file output) or
/pub/proposal.ps (postscript). Might be useful for
people to evaluate its overall structure in relation
to lisp, and I'm sure the people involved would be
interested in any comments.
∂07-Jan-87 1822 sdcrdcf!stephen@LOCUS.UCLA.EDU request
Received: from LOCUS.UCLA.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 87 18:22:15 PST
From: sdcrdcf!stephen@LOCUS.UCLA.EDU
Received: by sdc.uucp (4.12/sdcrdcf)
id AA00697; Wed, 7 Jan 87 16:40:28 pst
Message-Id: <8701080040.AA00697@sdc.uucp>
Received: from BIRDY by sdcrdcf with PUP; Wed, 7 Jan 87 16:40 PST
Date: 7 Jan 87 16:40 PST (Wednesday)
Subject: request
To: cl-windows%sail.stanford.edu
Cc:
please include me on the Commonlisp window system list.
stephen russell
sdcrdcf!stephen@locus.ucla.edu